[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
facilities.
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
package,
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
dependency.
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
<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
is
>> 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
>ideal....
>
>Comments? Suggestions?
>
>Loren
>
begin 666 ALUG.vcf
M0D5'24XZ5D-!4D0-"DXZ.T%,54<-"D9..D%,54<-"D]21SI!3%5'.TEN9F]R
M;6%T:6]N(%-E<G9I8V5S#0I4251,13I#:&%I<FUA;@T*3D]413M%3D-/1$E.
M1SU154]4140M4%))3E1!0DQ%.BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BH],$0]
M,$%4:&4]#0H@06YT=V5R<"!,:6YU>"!5<V5R($=R;W5P/3!$/3!!(#TP1#TP
M06$@;F]N+7!R;V9I="!C;W)P;W)A=&EO;B!C;VUP;W-E9"!O9B!S/0T*='5D
M96YT<RP@<')O9F5S<VEO;F%L<STP1#TP02!A;F0@9V5N97)A;"!C;VUP=71E
M<B!U<V5R<R!D961I8V%T960@=&\@=&AE('5S93T-"B!A;F0@9&5V96QO<&UE
M;G0@;V8],$0],$$@3&EN=7@@+2!A('!O=V5R9G5L+"!O<&5N+"!F<F5E;'DM
M<F5D:7-T<FEB=71A8FQE(&,]#0IO;7!U=&5R(&]P97)A=&EN9STP1#TP02!S
M>7-T96T@*$]3*2!F;W(@26YT96P@4$,G<RP@4&]W97)00W,L($1%0R!!;'!H
M84%84',L/0T*(%-005)#+"!E=&,N/3!$/3!!(#TP1#TP02!-965T:6YG<R Z
M(&5V97)Y(#%S="!7961N97-D87D@870@,3EU-#4L/3!$/3!!/4$P/0T*/4$P
M/4$P/4$P/4$P/4$P/4$P/4$P/4$P/4$P/4$P/4$P/4$P/4$P/4$P/4$P/4$P
M/4$P($=R87-P;VQD97)L86%N(#,R+#TP1#T-"CTP03U!,#U!,#U!,#U!,#U!
M,#U!,#U!,#U!,#U!,#U!,#U!,#U!,#U!,#U!,#U!,#U!,#U!,#U!,"!(;V)O
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
M=&T],$0],$$@*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*CT-"BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ/3!$/3!!#0I4
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
M86%N(#,R.TAO8F]K96XM4&]L9&5R.T%N='=E<G!E;CLR,#$X.T)E;&=I=6T-
M"DQ!0D5,.U=/4DL[14Y#3T1)3D<]455/5$5$+5!224Y404),13I,:6YU>#TP
M1#TP04=R87-P;VQD97)L86%N(#,R/3!$/3!!2&]B;VME;BU0;VQD97(L($%N
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:75M#0I,04)%3#M(3TU%.T5.0T]$24Y'/5%53U1%1"U04DE.5$%"3$4Z5F%N
M($QU<'!E;G-T<F%A=" W,#TP1#TP04%N='=E<G!E;BP@06YT=V5R<&5N(#(P
M,3@],$0],$%"96QG:75M#0I54DPZ:'1T<#HO+W5S97(N9VQO+F)E+W!O92]A
M;'5G+FAT;0T*55),.FAT=' Z+R]U<V5R+F=L;RYB92]P;V4O86QU9RYH=&T-
L"D5-04E,.U!2148[24Y415).150Z<&]E0&=L;RYB90T*14Y$.E9#05)$#0H`
`
end