Chapter 13 again ...
Having been advised (by private email) that the rpm thing was a FAQ,
I've skimmed the archives, and the only thing I could find near what I
was bothered about was "standardising the install package", a two-mail
thread in September 1998. (The easily accessible archives don't go much
further back.)
Michael Voase brought up the subject of a "registry", and Stuart
Anderson came back with the response that a standard file format (rpm)
was fine, but anything more could well interfere with innovation in the
package management area.
Unfortunately this promptly destroys the requirement for different
package managers to co-operate. It's all very well permitting unfettered
competition between managers, but it is currently impossible to
guarantee that one package manager will (even minimally) work reasonably
with a distribution based on a different manager. rpm won't work on
Corel, dpkg won't work on SuSE. And it doesn't matter a damn whether my
distro is LSB compliant, if my security manager demands that all
sensitive packages are compiled from source then my *installation*
CANNOT be LSB compliant :-(
It would also be nice if commercial companies (e.g. Corel) had some way
that their fancy installer could tell that "you need to install libc5"
before you found out the hard way when WP refused to start running :-(
To this end, what do people think of the following
extensions/alterations to chapter 13? Note that the purpose is to
specify the absolute minimum, to permit "package management innovation".
------------------------------------
Chapter 13. Software Installation
<add>
This specifies a standard file format for packages to be distributed in
(rpm), and a minimal database whereby installation programs can query
and update what packages and dependencies are already on the system.
A compliant Package Management Program may implement extensions provided
it does not require those extensions to be present in order to provide
minimal functionality, and it does not interfere with the correct
functioning of any other Package Management Program.
</add>
13.1 Package Format <leave as is>
13.2 Package Tools <leave as is>
13.3 Registry Format and Package Names <rewrite of existing 13.3>
<note> This should crib heavily from the Debian and RPM database
formats. I know neither so this may need some considerable input from
the more knowledgeable </note>
The database shall consist of the following directory structure:
/var/packagedb/<i>category</i>/<i>package-version[-distro]</i>
where the package-version-distro is probably a file.
The pathname for any particular program shall be dictated by the program
maintainer and not the packager. This ensures that all compliant
distributions will use exactly the same name for the same package.
<note> it also avoids any political fighting :-) </note>
13.3.1 Category
Is used to group similar packages together. For example "databases",
"corelibs", "X11", "Gnome", "KDE", "Games". Sub-categories are
permitted, should there be sufficient packages to make this worth while.
Rather importantly, "hardware" is a category. This then makes it
possible either for auto-detect programs to create the hardware
hierarchy automatically, or for manufacturers to supply the appropriate
file for inclusion in this directory.
<note> Maintenance programs can then avoid installing loads of drivers
just to make sure they've got the right one. Not least, this avoids the
problem of an unnecessary driver locking the system by auto-probing an
unfortunate memory address... or package managers insisting on
installing drivers for non-existent hardware :-( </note>
Also package managers can have their own "category" directory. This can
be used for private databases or whatever to enable things like rpm's
"what package does this file belong to"
13.3.2 Package Naming and Versioning
The full name of a package must consist of two elements specified the
program maintainer, and an optional third element specified by the
packager. These are separated by hyphens, which may not be used to
subdivide an individual element.
The first two elements, specified by the program maintainer, are the
package name and version. The third element identifies the package as
packaged up by the packager. Sub-elements should be separated by dots.
An example name would be
foobar-3.1.10-distro.arch.1
for the first release by distro on arch of the package foobar v3.1.10.
You might also have foobar.source-3.1.10 and foobar.devel-
3.1.10-distro.arch.3
13.3.3 package-version[-distro] (file content - software)
This is a file containing various bits of information. Probably pretty
much what is already in the rpm database - the main installation path of
the package, the pathnames of the components, a list of what depends on
this package, a list of what packages depend on this package etc.
Importantly, it also contains three sections, [superset of], [equivalent
to], and [subset of]. If it has the -distro extension it *must* list the
equivalent standard version somewhere if it is appropriate to do so.
This is where a package needing foo-2.4.1 discovers that foo-2.4.4 is
installed, and that the two are compatible (or not, as the case may be).
<note> bearing in mind that linux itself uses a slightly odd numbering
system (the minor development/stable scheme) and many other packages
e.g. glibc are not written specifically for linux, this way of
specifying compatibility seems to be the simplest. Trying to enforce a
standard numbering scheme would be like herding cats :-) </notes>
Package Managers may manipulate standard sections, or private sections
they have created for themselves; but they may not modify other
managers' private sections and must allow for their private sections
being invalidated by other managers.
The files must be text to permit easy modification by administrators if
required. (Do we permit the structure or parts thereof to be tgz'd? -
emacs seems quite happy with this.)
13.3.4 package-version[-distro] (hardware)
There is probably not much point specifying what is to be found here.
The manufacturer will put whatever configuration information they want,
which might include hints to the driver, information to enable a generic
driver to work out exactly which variant of the hardware it has got, etc
etc.
</rewrite>
13.4 Package Tools <new section>
The following commands will be supplied as part of any Package
Installation Program ...
here follows a list of commands that will add a package, check whether
dependencies are available, add a list of components, etc etc.
There is a good chance that this will just be a standard tool kit that
is used by all Package Installation Programs, and I would certainly
think that this should be the case. I would also hope that it specified
both a CLI interface and a C interface, so that it is easy to access
from both scripts and binaries.
<note> this is particularly intended for people who tend to "roll their
own" set-ups ... it means "make" can keep the dependency database up-to-
date </note>
13.5 General requirements for Package Installation Programs <new
section>
This should be a simple statement of what is required to make a good
general purpose Package Installation Program. Such things as conditional
dependencies, "install this if all pre-requisites are met", "install if
one pre-requisite is met", "install this regardless", "refuse to
install if something is missing" etc etc. It should be treated as a
guideline, and of course is irrelevant if someone is writing a one-off
installer for just their program. But it's a good guide to someone
writing their own setup as to what should be included.
------------------------------------------------------
Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999
Reply to: