[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SEUL: Re: Repost: Intended Package Management features
What about existing software packages that aren't equiped with this
I find that it is a big misstake to ignore these. As Users/maintainers of a
site if the
package is worthwhile surely will install this.
The package install program should in this case check which files are in the
generate a filelist with filenames (eventually dates, versions) and see if
those files already exist on the installed system.
In case it isn't installed it generates a entry for that file and a
In case it is already installed it has to check the version if it is
possible (if it is newer it should generate a backup copy, if it is older
it should not be installed since newer versions should be backward
compatible unless otherwise stated in the install doc)
otherwise it should generate a backup copy of the original file and warn the
maintainer of the computer for a manual check.
For the moment every system I know of ignore these -unstandard- packages and
runs in steep problems when you install/remove/update such packages
depending on older, required, uncompatible elements.
This can be greatly reduced by this kind of method.
Patrick Op de Beeck
The Antwerp Linux User Group
a non-profit corporation composed of students, professionals
and general computer users dedicated to the use and development of
Linux - a powerful, open, freely-redistributable computer operating
system (OS) for Intel PC's, PowerPCs, DEC AlphaAXPs, SPARC, etc.
Meetings : every 1st Wednesday at 19u45,
Hoboken-Polder (Antwerp, Belgium)
Email : email@example.com
Homepage : HTTP://user.glo.be/poe/alug.htm
From: Loren S Osborn <firstname.lastname@example.org>
Cc: email@example.com <firstname.lastname@example.org>
Date: jeudi 8 janvier 1998 6:01
Subject: Repost: Intended Package Management features
>From email@example.com Thu Dec 11 19:31 EST 1997
>From: firstname.lastname@example.org (Loren S Osborn)
>Subject: Re: other features
>To: email@example.com (Loren S Osborn;941;icsg1;)
>Date: Thu, 11 Dec 1997 19:34:08 -0500 (EST)
>X-Mailer: ELM [version 2.4 PL25]
>Content-Type: text/plain; charset=US-ASCII
>> As for the package management: Package management is the one thing that
>> most basic to a distribution, so it will be a big deal to use a brand new
>> one. That's not to say we shouldn't do it. My question is: What features
>> do we want to have in package management system that doesn't exist in
>> either RedHat's or Debian's? (and are we sure that those features aren't
>> about to be added in the next release of one of those?)
>Some features I had in mind for the package manager are:
> I) package manager/package management format:
> 1) source code distribution (two advantages:
> one package for all platforms, some programs need to
> be recompiled as part of the configuration process. )
> 2) package manager automatically compiles packages as part
> of the installation process ( without needing
> special instruction or CLI from the user). One
> of the parts of the package-file format instructs the
> installer as to how to compile and install the
> 3) all packages include a module for a command-line/
> menu-driven/GUI configuration tool, instructing the
> tool how to read/write the configuration files for the
> packages programs (both the user's "dot"-files and
> system-wide configuration files.)
> I'd like this tool to be modeled after "Figurine"
> (http://www.foxnet.net/~apenwarr/figurine/) as
> opposed to programs like "The Dot-file Generator",
> because figurine can both read hand-modified files,
> even retaining comments, and generate modified versions
> of those files without disturbing the comments, etc,
> in the original hand-modified version.
> This would probably be the hardest part of this
> 4) it would contain dependencies (a given) it will also require
> a small suite of test cases that the installation
> program can perform to verify that the package is
> properly installed, and functioning correctly. It
> would also contain memory requirements, and any other
> hardware constraints.
> 5) the package manager would be smart enough to warn the user
> if other packages rely on a package being removed, as
> well as indicating libraries no longer in use after the
> removal of a package, that he/she may wish to remove
> 6) the package manager could automatically check for new
> versions any packages installed on the system.
> 7) could be in a standard fileformat (such as a "tarball")
> with a requirement for certain special files in it.
> (it would probably have a different extention for
> identificication purposes) It could simply be a
> "tarball" containing:
> the original author's original source-code
> a file containing dependencies, hardware
> requirements, and a script that
> verifies that the package is installed
> and functioning properly.
> the configuration-tool modules,
> compiling and installation instructions,
> a PGP signature (from the package management
> tool maintainers) verifying that it
> went through part "II" below.
> II) Distribution and Validation: I believe we shoul have several
> computers/mirrors strewn around the "net" that do the
> 1) a package, as above, is submitted to one of these
> "Easy Linux Package Verification" systems,
> either by the program's author (hopefully),
> or someone who voulenteered to maintain the
> package for this program.
> 2) It runs Linux in emulation on several different (emulated)
> platforms, with the bare-bones requirements, verifying
> that the test cases pass.
> If they do it happily slaps a PGP signature on
> it, coppies it to the public FTP directory,
> and sends email to the maintainer stating so.
> If not, it gets rejected, and the maintainer gets a
> diagnostic email indicating what went wrong
> in what situations... (ie. if it states that
> it requires an x86, it won't be tested with an
> 3) The server watches for new versions of the source code
> "tarball" and attempts the same validation of the
> new version with the old files...
> If it passes, it tags it as "incomming", slaps a PGP
> signature on it, coppies it to the public FTP
> directory in the "incomming" section, and sends
> mail to the maintainer indicating such.
> If not, it gets rejected, and the maintainer gets a
> diagnostic email as above...
> In both cases the old version stays on the server.
> 4) If the package get's tagged as "incomming" the maintainer
> then has two choices:
> He/She can say "leave the configuratoin options, and
> dependencies alone", in which case the
> "incoming" tag will be removed, and the new
> version will replace the old,
> Or, he/she can change them, and re-submit it as in step
> 2... (when it gets validated, the old version
> will be replaced)..
>It's a bit overwhelming, but this is the system that I would consider
begin 666 ALUG.vcf
M,$%(/0T*;VUE<&%G92 Z($A45% Z+R]U<V5R+F=L;RYB92]P;V4O86QU9RYH
M.BLS,B S+S(Q." V,R U- T*0412.U=/4DLZ.TQI;G5X.T=R87-P;VQD97)L