Chapter 13 again ...

[Shaya Potter]

On Tue, 18 Jul 2000 tytso at mit.edu wrote:

> 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.")

Ted, I'm no slackware lover, but you don't have to get into attacking
slackware.  Some people like it, and that's good enough.  In reality,
Alien works on slackware just like Alien works on Red Hat and Debian.  It
lets you install a foriegn package with the package manager that is native
to that distribution.  One might argue on the merit of slackware's native
"package manager", but slackware users could just as easily install LSB
packages as Debian users could (or Red Hat users could install DEBs if
they had Alien installed)

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

True, but one most also remember that imposing the RPM utility on others
is also a bad idea.  The LSB should (IMHO) maybe rely on the RPM format,
but use a more general interface, so that one might easily wrap it around
rpm, or around a alien/dpkg or alien/slackware'ish installation.

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

"single" formats are good and bad.  They are good in the fact that
everyone can use them, but they are bad in the fact that they restrict
development in new directions, as you have (or want) to remain compatible
with everyone else.

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

hmm, should have read this before I typed the above. :)  This is an
important point that has to be stressed over and over again, so I don't
mind the time I spent typing it.

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

I don't know what "trigger scripts" are in the RPM world, I assume you
mean that a package can only use "post install" scripts (such as updating
inetd, cron, rc.d structure.....) that the LSB defines to be LSB
compatible.

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

no arguments here.

shaya potter
-- 
spotter at ymail.yu.edu   spotter at yucs.org   spotter at us.ibm.com