Re: Chapter 13 again ...
PLease stop sending me these e-mails
> Date: Fri, 14 Jul 2000 23:44:12 +0100
> From: "Anthony W. Youngman" <firstname.lastname@example.org>
> 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
> was bothered about was "standardising the install package", a
> thread in September 1998. (The easily accessible archives don't go
> 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
> 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 email@example.com
> with subject of "unsubscribe". Trouble? Email
Owner Operator Genesis Connections