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
