Re: Packaging and installation
In message <Pine.LNX.firstname.lastname@example.org>,
Jeffrey Watts <email@example.com> writes
>On Tue, 24 Oct 2000, Nicholas Petreley wrote:
>> In other words, people aren't really saying "EVERYONE MUST USE RPM",
>> they're saying "LET'S STANDARDIZE ON RPM AND IF ANYONE DISAGREES, LET
>> THEM USE ALIEN". That way lies irrelevance and chaos.
>Nick, you are vastly misstating the situation.
This post has for me clarified the situation wonderfully. Let me state
clearly what is wrong with the current position.
EITHER we are arguing about package format
OR we are arguing about dependency management.
If we are arguing about package format there is a clear winner, and it
is NOT rpm. It is tgz (or cpio), which is native to all nixen, and a
damn sight more besides. The mere statement "non rpm distros can use
alien" instantly invalidates rpm as a candidate.
But if we are arguing about dependency management, then the rpm file
format is irrelevant. Somebody said that Slack doesn't have a package
database. In other words EITHER Slack can NOT be LSB compliant, OR there
is no point for Slack in being compliant. If Slack has no package
database, what is the point of adding alien as a package?
Nick's point and mine is "What is the point of being LSB compliant?" As
I see it, if you are correct in saying that the whole argument is about
file formats, then all the LSB guarantees is that a package will
"install" (for a random value of "install"). THERE ARE NO GUARANTEES
WHATSOEVER THAT THE DEPENDENCIES WILL BE MET AND THE PACKAGE WILL
Nick has pointed out that it is possible to install a package which
relies on ncurses, on an LSB compliant system (which guarantees ncurses
support), and you still have a 50/50 chance that the program will crash
and burn when you try to run it.
In those circumstances, WHERE IS THE ADVANTAGE OF RPM OVER TGZ? There
The whole point of rpm is that it contains a load of dependency
information. But if all we're arguing about is the file format, then
that information is irrelevant and can be left out. In which case we're
left with a cpio archive (which leads to the obvious conclusion that
cpio should be the package format, not rpm).
In other words, if we're arguing about file formats, lets delete ALL
dependency information from the file. And that leaves us with a cpio
archive, so lets define cpio as the standard file format. And if we
decide that some of the information we've just deleted is actually
necessary, then we're not arguing about file formats, we're arguing
about dependencies, and the file format is irrelevant (avctually, it's
orthogonal) to the problem.
Please can someone explain to me how the LSB is going to guarantee that
the package I've just installed is actually going to work without
crashing and burning. And I defy you to do it without bringing
dependencies into the picture (unless everything is huge statically
linked executables). Once we've brought dependencies into the picture,
the file format is irrelevant. We need an api, not a file format.
>We're not saying that anyone must use RPM as a package manager. We're
>specifying that the packaging format for 3rd party apps must be RPM's
>format. Each distribution will provide a tool (like alien) that will
>install this RPM _format_ package onto their system. Remember that all a
>.rpm package is is a cpio archive that includes software and organization
>(install scripts, dependencies, etc).
>What you're arguing for is something that is outside of the current LSB's
>scope. We're trying to standardize what's _in_ a GNU/Linux distribution,
>not HOW the distribution is set up. We're not about to dictate how folks
>do value-add, we just want a common baseline so software is portable.
>Now, I think you're idea has merit, but what you're asking for is a system
>that would be unacceptable to many distributions (especially ones like
>Slackware, that don't use package management). It is not LSB's mission to
>dictate or provide a package _management system_. That's a side project.
>I'm sorry if what I've said has come across as "we've already decided on
>RPM so tough, go away". That's not how I meant it. I meant it more like
>"we've covered this topic in depth and RPM was the best solution by far".
>The reason that most of us are reluctant to talk about it is that most
>folks who bring this up want to re-evaluate the decision from the ground
>up, instead of researching all of the issues involved and the dialogue
>that has gone before.
>I know that finding all the dialogue in the mail archives may be
>difficult, but personally I'm not willing to argue with folks that haven't
>done the footwork and don't know the issues involved. Heck, I don't know
>that much, but I lurked on this list for about 6 months before replying to
>emails because I wanted to make sure I understood some of the issues. I
>didn't want to waste the time of folks whose time is precious.
>The fact that most of the folks responding to this thread don't realize
>that we're talking about the RPM _format_, and not the _package management
>system_ serves to illustrate my point perfectly. Debian GNU/Linux would
>not give up their package manager or tools with the LSB. They would just
>have a tool to install 3rd party applications.
>This is a FAQ. However, I don't know of a FAQ for the LSB. I think one
>is VERY necessary, because these same miscommunications come up every
>couple of months, and I wish there was a concise document that we could
>direct folks to so we didn't have to keep discussing the same thing over
>and over again. I understand your frustration, and I'm sorry I didn't
>spend more time explaining my statements.
>By the way, is it "Nick" or "Nicholas"? I seem to see both used...
>Thanks for your patience,
>| Jeffrey Watts |
>| firstname.lastname@example.org o-----------------------------------------o
>| Systems Programmer | "Proprietary system advocates aren't |
>| Network Systems Management | evil or stupid. They are the victims. |
>| Sprint Communications | They have a disease and they need |
>o----------------------------| help." |
> | -- Donald B. Marti Jr. |
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
The Science of Discworld : (c) Terry Pratchett 1999