[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,
                   Graspolderlaan 32,
                   Hoboken-Polder (Antwerp, Belgium)
Email           : poe@glo.be
Homepage : HTTP://user.glo.be/poe/alug.htm

-----Original Message-----
From: Loren S Osborn <lso8219@cs.rit.edu>
To: kde-distribution@thunder.dorm.duke.edu
<kde-distribution@thunder.dorm.duke.edu>; seul-project@seul.org
Cc: omega@seul.org <omega@seul.org>
Date: jeudi 8 janvier 1998 6:01
Subject: Repost: Intended Package Management features

>Reposted message:
>From lso8219@cs.rit.edu Thu Dec 11 19:31 EST 1997
>From: lso8219@cs.rit.edu (Loren S Osborn)
>Message-Id: <199712120034.TAA02187@buddy.rit.edu>
>Subject: Re: other features
>To: lso8219@pony-express.cs.rit.edu (Loren S Osborn;941;icsg1;)
>Date: Thu, 11 Dec 1997 19:34:08 -0500 (EST)
>X-Mailer: ELM [version 2.4 PL25]
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Content-Type: text/plain; charset=US-ASCII
>Content-Length: 4914
>> 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
> package.)
> 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
> project.
> 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
> "tarball"
> 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
> following:
> 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
> alpha)
> 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
>Comments? Suggestions?

begin 666 ALUG.vcf
M84%84',L/0T*(%-005)#+"!E=&,N/3!$/3!!(#TP1#TP02!-965T:6YG<R Z
M:V5N+5!O;&1E<B H06X]#0IT=V5R<"P@0F5L9VEU;2D],$0],$%%;6%I;#U!
M,#U!,#U!,#U!,#U!,#U!,#U!,#U!,#U!,#U!," Z('!O94!G;&\N8F4],$0]
M,$%(/0T*;VUE<&%G92 Z($A45% Z+R]U<V5R+F=L;RYB92]P;V4O86QU9RYH
M14P[5T]22SM63TE#13HK,S(@,R R,3@@-C,@-30-"E1%3#M(3TU%.U9/24-%
M.BLS,B S+S(Q." V,R U- T*0412.U=/4DLZ.TQI;G5X.T=R87-P;VQD97)L
M='=E<G!E;B R,#$X/3!$/3!!0F5L9VEU/0T*;0T*0412.TA/344Z.SM686X@
M3'5P<&5N<W1R86%T(#<P.T%N='=E<G!E;CM!;G1W97)P96X[,C Q.#M"96QG
M($QU<'!E;G-T<F%A=" W,#TP1#TP04%N='=E<G!E;BP@06YT=V5R<&5N(#(P
M;'5G+FAT;0T*55),.FAT=' Z+R]U<V5R+F=L;RYB92]P;V4O86QU9RYH=&T-