Re: Chapter 13 again ...

[tytso@mit.edu]

   Date: Fri, 14 Jul 2000 23:44:12 +0100
   From: "Anthony W. Youngman" <wol@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
   further back.)

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
    without.

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.

						     - Ted