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


Jim Knoble wrote:
> På 2000-Mar-15 klokka 19:45:41 -0500 skrivet Robert W. Current, Ph.D.:
> : Jeffrey Watts wrote:
> : > I agree, but a common package format is desirable, and RPM is adequate
> : > enough technically, and it has the dominant mindshare.  It makes an
> : > excellent choice for a standard.
> :
> : I disagree.  Maybe writing to the RPM database should be considered for
> : standardization, but not endorsing RPMs.  Maybe working within RPM
> : development to make the accounting widely readable and manageable for
> : all packaging systems, would be good, but not endorsing RPM.
> Why not?

Interesting fundamental question of development.  I'll get back to that.

> RPM is available now, it works, people use it, and Jeff
> Johnson has done and continues to do a fantastic job of managing and
> integrating needs from all sorts of camps (including non-Linux ones)
> while keeping a clear vision of RPM's goals and design.  The only major
> shortcoming in RPM that i'm aware of is the severe lack of current
> documentation.

Yes, even the BSD's can install RPM's now, and RPM is in most of the
"Free" BSD ports.
> The only other currently existing packaging system worth the same salt
> is Debian's, with which i have little enough experience that i cannot
> properly criticize it.

I'm not the guy to answer that.  Other than dependency fetching, DEB
does it, RPM doesn't yet (to my knowledge, or does it?)
> In short:  RPM is (a) available, (b) proven, (c) widely used, (d)
> technically capable, and (e) actively supported and developed.  

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."

> I can
> see little room or rationale for discarding it.

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.

Historically, and logically, there is proven merit in competition of
software development.  Gnome vs. KDE for example, the world may benefit
from combining them... But the less they were "pushed" to do it, the
more they worked together.

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.

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).

Reply to: