Chapter 13 - Software Installation
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
Reply to: