Re: RFC

[Jim Knoble <jmknoble@pobox.com>]

På 2000-Mar-15 klokka 23:30:16 -0500 skrivet Robert W. Current:

: All true.  Proving RPM is a very valuable tool.  I have no problem
: saying "RPM is a good packaging method."  I have a problem saying "RPM
: is the only packaging method Linux users should use."

LSB isn't saying that.  LSB is saying ``RPM is the one packaging method
ISVs can be guaranteed will work on an LSB-compliant system.''

: Well, throwing out it is strong wording.  What I am saying is, to cut
: out the competitiveness of other packaging systems, and the redundancy
: of the projects is probably unwise.  If Debian and Slackware want to
: throw out their packaging in favor of RPM, that should be their choice,
: not something forced on them.

The LSB is not interested in replacing vendor packaging systems in
Linux distributions.  It's much more interested in providing a single
packaging format that will work on all of them.  If the distribution
vendors prefer to implement (or continue to support) a different
packaging system, while still or additionally providing support for RPM
packages, that is just fine.

: Packaging is still evolving IMHO, so all methods should be encouraged
: to do all they can to make themselves better, and grow.  It's totally
: unfair to just flat out discount all other packaging methods simply
: because RPM is popular and functional.

I don't believe `fairness' has been one of the characteristics
attributed to the evolutionary nature of open source software.  If it
is better, people will begin to use it.  That's what happened with RPM
and other packaging methods (including BSD ports) over gzipped
tarballs.

: But the real question is, how necessary is adopting a "standard
: package" vs. simply specifying a standard package accounting system.
: Countless Debian users would cheer to know they could still use their
: favorite tool, and if it starts accounting in the same way as RPM, then
: all the better.  To just cut it off at the knees is unnecessary (IMHO
: again).

What you're calling a ``standard package accounting system'' is the
other end of what the RPM package format is:  the RPM package contains
all the necessary package/dependency/file information to install (as
you've pointed out) in any number of environments, including not only
package-oriented systems such as Debian but also other systems such as
Slackware and the BSDs.

There does not currently exist any such standard package accounting
system.  If LSB were to specify one, how would we know it would work
when implemented, or that folks would use it?  LSB doesn't have enough
packaging experts to devote resources to figuring out what such an
accounting system should look like.  Furthermore, since no such system
exists, there are currently no packaging tools that support such a
system.  All the warning signs say a package accounting system like you
suggest is a poor choice.

In contrast, we know they would use RPM (they do already), we know RPM
would work (it does already), and it already exists.  Let's learn from
the IETF and standardize what already exists, works, and has most of
the kinks worked out[*].  Doing so will not keep packaging technology
from evolving.  Distribution vendors and other folks will continue to
use or create whatever fills their needs.

[*] It could even be argued that `alien' fills the requirements of a
    second sample implementation.

-- 
jim knoble
jmknoble@pobox.com