Chapter 13 again ...
tytso at mit.edu
tytso at mit.edu
Mon Jul 17 21:01:07 PDT 2000
Date: Fri, 14 Jul 2000 23:44:12 +0100
From: "Anthony W. Youngman" <wol at thewolery.demon.co.uk>
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
Sigh, OK. So let's go over this, one more time.....
1) The reality is that RPM is the de-facto standard. Just about all
modern distributions support RPM files; even Debian can read RPM
files, using the Alien package. (Slackware doesn't, but it's so
backwards in so many other areas that it wouldn't be LSB compliant
for all sorts of other reasons; in fact, some would claim that it
hardly qualifies as a "modern distribution.")
2) There has been some talk about a RPM/dpkg format merger that has
been underway for many months now. I don't know what it's current
status, but we can only hope. However that turns out, the LSB is
*not* the place to invent a new packaging format. If we did, it's
likely that the rest of the world would probably ignore us. The
reality is that a merger of the RPM and dpkg packet formats needs to
come from the RPM and dpkg folks, and not imposed on them from
3) What we are doing, then, is an interim measure, and is labelled as
such. Hopefully in the future there will be a single package
format, and it will be standardized and used by all distributions
(excepting maybe Slackware).
4) What we are standardizing is not a package manager, or the package
database. What we are standardizing is the package *format*. I.e.,
what the Independent Software Vendor will supply to users. How the
package is processed is, as they say in standards parlance, "a local
matter". (i.e,. none of our business; people will use some tool
that's a wrapper on top of RPM or alien/dpkg, as appropriate.)
5) Yes, we know that RPM's aren't necessarily compatible across
distributions. The way that we will address this is by strictly
limiting what dependencies a RPM can have. The only dependency that
it can assume the system will have will be something like
"LSB-1.0". (i.e., no libext2fs, or libc6.0, or other dependencies
which unfortunately arne't standardized across distributions.)
For compatibility reasons with Debian dpkg systems using aliens, we
will also sharply restrict what kind of trigger scripts can be
included with such RPM's.
6) There is no rule 6.
7) Application vendors are not *obligated* to ship RPM format files.
If they like, they can use their own tar.gz or cpio, or some other
wrapped executable format if they like. However, given that even
Windows 2000 has a package technology, it would be a shame if we
were to forbid application writers from using a modern package
management system. This approach seems to be the best, most
pragmatic approach that is most likely to win acceptance from the
distributions, the independent software vendors, and the users.
More information about the lsb-discuss