Future (RPM based) linuxen: RHEL, FC, WBEL, Mandrake, SuSE?

[Paul Iadonisi]

On Mon, 2004-04-05 at 13:36, Bill Sconce wrote:


> If anyone can stand another flip comment, we have often accused Microsoft
> customers of being used to their shackles, of being trapped by their biases.

  Absolutely.  Except that with Windows, you can NEVER have the
equivalent of something like Whitebox Enterprise Linux, Taos Linux,
CentOS, and cAos.  Not defending Red Hat's change in business, but at
least its contributing back significant amounts of GPL/LGPL software. 
So although the company is certainly getting free development work from
the Fedora Core community, I wouldn't call it a leech of a company.
  I just wish RHAT's stock was dividend bearing so stockholders could
truly share in the profits, instead of strictly counting on 'growth'. 
But, alas, dividends are mostly a vestige of the past, (slightly?) more
fair public market. :-(

[snip]

> The OP was "what to do as RH keeps changing".  Libranet isn't the answer for
> everyone, but it isn't sufficiently well known that there are alternaives to
> RPM.

<RPMBIGOT MODE=ON>

  This is my only real beef here.  It's perpetuated myth about rpm.  Rpm
is not, I repeat not responsible for the so-called dependency hell that
many Debianites (hehe) have pontificated about.  It has to do with the
much more centralized development deb packages.
  I can almost guarantee you that if Debian were rpm based, but
preserved every single other aspect of it's development process, it
would be as good as it is today and would have as few dependency
problems as it does today.
  If that were not true, then apt and synaptic would NOT be good on Red
Hat.  The very fact apt and synaptic work well on Red Hat, IMNSHO, is
proof positive that rpm is not the problem.   It's the lack of a clear
policy on rpm building that is followed.  That's where Debian has a
clear advantage.  (That is changing, by the way, with a project called
Fedora Tracker which is in it's embryonic stages right now.  But Debian
has definite lead in that area.)

</RPMBIGOT>

  My personal preference for a dependency resolution tool is, however,
yum.  Though it's mostly historical.  Apt used to make system() calls to
the rpm command line tools instead of using librpm, so there was no real
support for transaction type operations.  If I'm not mistaken, that's
now changed.  And there is actually a commom xml based metadata format
being worked on by the developers of apt, yum, up2date, (urpmi?), and
hopefully anything else that comes along.  So setting up a repository
for multiple dependency resolution tools will become probably an order
of magnitude easier.

--
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets