PLease stop sending me these e-mails
Quoting [EMAIL PROTECTED]: > Date: Fri, 14 Jul 2000 23:44:12 +0100 > From: "Anthony W. Youngman" <[EMAIL PROTECTED]> > > 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 [EMAIL PROTECTED] > with subject of "unsubscribe". Trouble? Email > [EMAIL PROTECTED] > > Mike McClimans Owner Operator Genesis Connections Visit:WWW.handtech.com/GenesisConnections
