SEUL: Repost: Intended Package Management features

[lso8219@cs.rit.edu (Loren S Osborn)]

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