I've just subscribed to the list, and was rather pleased to see a post by Santeri Kannisto on almost exactly the subject that made me subscribe.
I've just printed off and read the LSB 0.2pre. I had a load of difficulty doing so, too :-( [1] What interests me is "Chapter 13. Software Installation". <quote> 13.1 Package format The current "plan-of-record" is to specify RPM as the file format. It is supported either directly, or indirectly by the widest number of distributions, and so far, no one has pointed out any deficiencies. If you don't like this, then please propose an alternative. </quote> While I cannot find it at the start of the standard, I thought that the purpose of the LSB was "to provide a minimal subset that will guarantee interoperability between distributions". My two complaints are (1) that section 13.1 is grossly in excess of a "minimal subset", and the claim that rpms are supported "directly or indirectly by the widest number of distributions" is just plain false. What about tar? Using the dreaded Windows as an example, you have InstallShield as a widely used 3rd-party installation package. You have Microsoft's own package that comes with VB et al (Is that based on InstallShield?). And you have various "proprietary" installers such as WordPerfect's. Why on earth do we need to specify how a package is bundled up? Also, there are a lot of (maybe just perceived) faults with rpm. For example, I tried to install a SuSE distro on a machine with a small hard disk. It *insisted* on installing a load of drivers (ISDN, ALSA etc) for hardware that I didn't have, wasting at least 1% of very valuable disk real-estate. I gather this is a flaw of rpm, not SuSE. .deb's are supposed to be much better. And I have a lot of trouble installing rpms (RedHat) on my rpm-based (SuSE) distro, although this is addressed in the original document. And finally, what about those people who, in minor or major part, prefer installing using make? One of the biggest problems for many experienced users is that packages refuse to install because of a "missing dependency", when that dependency was installed as a "bleeding edge" source package, and for various reasons the admin can't/won't roll back to an earlier, packaged version. The reality is, that the "minimal subset" required is a standard layout for the package database. As a packager, I don't give a damn what package software other people use. But if the LSB restricts my packager, then they are infringing on my freedom! What I need to know is what packages, libraries etc are already there. If there is a standard package database then I can get that information. And I can also put my information into that database so that other packages can access me. This is both a minimal and a totally sufficient set. And this gives us a couple of other side effects too, namely that make files can update the database so that packages can see the bleeding edge, and that we can also manage the hardware the same way. While the below will need quite a lot of cleaning up, may I suggest the following as the basis of chapter 13... Chapter 13. Software Installation This specifies a standard way for any package installer to find out what is already on the system, and to notify other package installers about what it itself has installed. 13.1 Package Installation Programs All package installation programs must be distributed in one of two forms. Either as part of a distribution in which case they are guaranteed to run, Or as a statically linked binary without dependencies, in which case they are also guaranteed to run. In this case it is perfectly permissible to supply a minimal installer that installs the full package. <note> this is intended to ensure that any installation package can easily be installed on any distribution </note> It goes without saying that a source tgz is acceptable for the experts. 13.2 Installation Package Format Is irrelevant. All packages should be accompanied by the relevant Package Installation Program if the package is supplied on bulk media such as a CD, or by urls informing the installer where to obtain the Package Installation Program if the package is available for download. 13.3 Package Database Format <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... </note> 13.3.2 package-version[-distro] (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). 13.3.3 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. 13.4 Package Tools 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. 13.5 General requirements for Package Installation Programs 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. .............................................................. [1] When I tried to print 0.2pre off, it was available as html or rtf. I think the html was hypertext (ie loads of links and not printer friendly), and the rtf was definitely printer-unfriendly. Having loaded it into Word, I reformatted it for A4 at which point it put page-breaks in all sorts of stupid/unfortunate places. So I loaded it into WordPerfect, which it promptly near as damn hung, and once I managed to get it loaded, while it was nowhere as bad as Word as regards stupid formatting, it was pretty naff in its layout :-( -- 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
