[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Chapter 13 again ...

PLease stop sending me these e-mails

Quoting 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
> --
> To UNSUBSCRIBE, email to lsb-discuss-request@lists.linuxbase.org
> with subject of "unsubscribe". Trouble? Email
> listmaster@lists.linuxbase.org

Mike McClimans

Owner Operator Genesis Connections

Reply to: