Debian flamewar (plus a "GNU/Linux" rant)

Paul Iadonisi pri.lugofnh at iadonisi.to
Thu Feb 10 18:44:00 EST 2005


[As The Linux Lobbyist comes to life, he says...]

Oh, goody, my favorite flamewar! ;-)

On Thu, 2005-02-10 at 01:09 -0500, Jason Stephenson wrote:
> Heh..... I find this discussion mildly interesting from where I sit, a 
> mostly xBSD user.

  As preface, let me say that I like the BSDs somewhat, save the anti-
GPL bigotry among many of the developers that is usually accompanied by
a completely lack of understanding (or deliberate misrepresentation) of
its terms.

[snip]

>  we had multiple systems running HP-UX, 
> Solaris, IRIX, Red Hat GNU/Linux, Debian GNU/Linux, FreeBSD, and even 1 

  Hmm, "Red Hat GNU/Linux"?  Is that something new that Red Hat is
selling and/or distributing?  Because I've never heard of it before.
Funny...poking around http://www.redhat.com/, it looks like Red Hat has
heard of it either!  So I guess I'm not crazy.
  Okay, putting the sarcasm aside, I have no problem with referring to
Red Hat Enterprise Linux as well as Fedora Core as "GNU/Linux based
operating systems."  But as far as I'm concerned, when you put the
distribution together, you get to keep the naming rights.  Not the FSF.
Not the GNU project.  And not (sorry, I know he may be on this list, but
that's life) Richard Stallman.  For the record, I like and agree with
nearly everything, if not everything that has come from those three.
And if RMS and I hashed this particular issue out over a latte we'd
probably end up agreeing in the end.


> It was largely the issues of "package management" that made me decide to 
> go with FreeBSD and OpenBSD for my computers at home, instead of various 
> flavors of GNU/Linux. I found the ports collections to be the solution 
> to deb and rpm hells. In almost every case, I cd into the program's 
> ports directory, type 'make install' and the software builds, installs, 
> and then runs with no hitches. There's very little to package manage and 
> that's how it should be, IMHO.

  Ah, but you are demonstrating almost the exact disconnect that Ben
spoke about in his initial complaint about how the Debianites equate the
large collection of debs available at many mirrors with the
functionality of apt-get when apt-get is not at all unique and arguably
inferior to many of the equivalent dependency resolution tools available
in rpmland.
  What's missing in the GNU/Linux world (there, see?  I'm not totally
opposed to "GNU/Linux" usage ;-)) outside of Debian is a good process.
(Debian, of course, could use a little *less* process so that there is
an update more than once a decade.)  The tools are really there with
possibly some minor tweaks necessary.
  What the BSD ports collection seems to have is an excellent process
for making sure that everything works together.  I don't know how big
the ports collections are in the various BSDs, but its possible that
there is also more software than you will find in the typical GNU/Linux
distro (save Debian, of course).

> I experienced all kinds of problems on the Linux machines, mainly 
> because we were a research institution and the profs would need some 
> bizarre hardware combination that wouldn't quite work with the default 
> packages from the various releases. It became a nightmare trying to 
> maintain a machine loading packages from 2 different Debian releases, or 
> trying to install binary RPMs on some of the RedHat machines with 
> different kernels, etc.

  Wait, I'm have a little trouble understanding the problem.  What were
the problems specifically?  If you are saying that you needed to install
a custom kernel and because you did that (with make bzImage;make
modules;make install;make modules_install or whatever), then I think I
see the problem.
  It all comes down to packaging.  I'm a packaging fanatic.  I hate
stuff in /usr/local.  I also won't touch a 'make install' as root with a
ten foot pole that poops all over my filesystem.  I create rpms in my
sleep even.  If I were a Slackware fan, I'd create tgz's in my sleep.
The point is, an OS should be divided up into manageable chunks so that
they can be updated independently and without source.  Source is good,
but how many times, for example, do you want to build perl and answer
those questions?
  So, I've even going as far as foregoing the (rather baroque, IMO)
usually kernel compile/install.  Instead, I start with Red Hat's source
rpm file and make the mods there.  Add a tag to the Release: to indicate
it's changed and 'rpmbuild -bs SPECS/kernel-2.6.spec;rpmbuild --rebuild
--target=i586,i686,noarch SRPMS/kernel-<version>-<release>.src.rpm' and
a while latter I have some binary kernel rpms that keeps the dependency
tree in /var/lib/rpm consistent.  It's work, yes, but once you master
it, it's *much* easier to diagnose many classes of problems.
  You master the OSes you need to deal with.  What I'm saying is that
your choice to go with BSDs in some places was very likely the right one
for you, particularly if you had more of an interest in learning them
because that inertia alone would help you in managing those machines.

> It soon became routine for my colleague and I to install nearly 
> everything from source code on certain machines because we knew that the 
> packages would not work.

  Again, the problem was probably one not having anything to do with the
principles behind using binary rpms.


> I can't count the number of times I've had
> 
> apt-get update
> apt-get install
> 
> fail and for what reasons when.
> 
> I've also dealt with RPM-hell of having to install RPM after RPM, just 
> to get the one thing that I want to use installed. I've also had 
> installs fail on some machine, again because of custom packages needed 
> for one reason or another.

  The problem is not the tool, but how it is being used.  Either by you
or the packager(s).  More likely it's the latter.
  So called RPM-hell is a myth.  Before I get flamed for that, let me
explain.  When rpm bitches about dependencies, it is doing *exactly*
what it was designed to do.  If I were a betting man I would wager that
a good 70-90% of the so-called rpm-hell problems have direct cause
related to the admin of the machine doing several of the following
commands over time:

rpm -ivh --force <package.rpm>
rpm -ivh --nodeps <package.rpm>
./configure;make;make install

  The remainder of the problems either have to do with a) mixing
repositories that have explicit warnings about mixing with certain other
repositories b) grabbing random rpms from joeblow.com and installing
them without doing any kind of due diligence checks, c) using rpm
barebones instead of the provided depsolving tools (yum, apt-rpm,
urpmi), or d) genuine packaging problems that the packager needs to fix.
  And maybe less than 1% are real bugs in rpm or any kind of problem
with philosophy behind rpm.

> I can tell you that I've only ever had two package fail make install in 
> FreeBSD ports because one time I updated right after a change to one 
> package, and the second time because the package maintainer had written 
> his makefile to check for the headers from a specific version of the 
> mysql libs and I'd installed a more recent one. In both cases, the fixes 
> were simple changes to the makefile that I sent off to the package 
> maintainers. One was incorporated into the makefile, and the other 
> maintainer wrote back thanking me, but that he'd already updated the 
> repository with a "better" change.

  And those kinds of problems happen with rpms, too, but can be
addressed nearly identically: contact the packager or grab the source
rpm and fix it yourself if it's not too complex.
  Again, it's about mastering the OSes that you have to deal with.
That's assuming, of course, that the OS gives you the tools to
accomplish the task.  The rpm and depsolver suites of tools certainly
provide those capabilities in the vast majority of the cases.

[snip]

> Oh, and don't get me started on the "package management" in IRIX, HP-UX, 
> and Solaris. They have varying degrees of success and failure, and you 
> often have to go to third party sources on the Internet or resort to 
> installing things from source for the useful stuff.

  Hehe.  There, I can agree 100%.  :-)

> Anyway, to me, it isn't software without source code, and I do prefer to 
> install from source because then you know it works with the libraries 
> installed on your system because it was compiled against those very 
> libraries. You don't need to worry about binary compatibility issues 
> between different library and kernel versions busting your binary 
> packages. Yeah, you could end up with something that doesn't compile, 
> but at least then, you can see what the problem is and fix it yourself.

  True, but you also may loose all record of your fix if you forget
which source tree is which.  It's much easier to backup a single source
rpm that has your patch and comments recorded in the spec file.

  I also find this discussion somewhat interesting because there have
been at least a few recent threads on the fedora-devel and fedora-test
lists about depsolver tools.  The developer of yum (Seth Vidal) is on
those lists and though he is quite understandably biased toward yum, he
is always willing to engage in conversations about ways to do it better.
  My personal take is that at least the majority of participants in
those discussions are not adamant about one depsovler or another, but
just want whatever is chosen as the default to do-the-right-thing-
dammit, which is my position.

On the Red Hat (rpm) vs. Debian (dpkg) debate:
  I posed a challenge some time ago on this list for anyone familiar
with deb package internals and/or dep packaging building to list, point
by point why dpkg was superior to rpm.  The condition was that apt-get
be left out of the discussion completely.  My reason was the same as
Ben's: it's apples an oranges.  You wan't to compare yum vs. apt-get vs.
smartpm vs. urpmi?  Fine.  But that's all moot now that apt4rpm exists,
isn't it?

  Nobody took the challenge.

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




More information about the gnhlug-discuss mailing list