[ale] linus doesn't like Debian?

[James P. Kinney III]

On Thu, 2007-08-23 at 10:58 -0400, Michael B. Trausch wrote:

> 'yum', as best as I understand it, is a horrid hack on top of a
> collection of hacks that is RPM.  I could be wrong, and if so, please
> correct me---but a new utility in the toolbox won't fix the
> architectural problems that have plagued RPM since at least 1996/1997
> when I first had my hands on a Red Hat system.
> 
> I stuck with Slackware, and was turned off to the concept of package
> managers for a long time until I picked up Ubuntu.  It makes me wish
> that I'd tried Debian earlier.
> 
Too bad you don't have good experience with rpm and yum. So many people
don't understand the process and how it is designed to work so they
gripe and moan about how broken it is without ever learning how it is
trying to save their backside. 

The dependencies for a complex application are, as any programmer knows,
determined by what is used to write the application: from the gui
toolkit to the libs, it all has a version number and it matters.

If I compile an application with glibc v. 2.7 and you are using glibc v.
1.8 there is a likelihood that the application will perform poorly, or
worse - cause a system crash.

To give credit where it is due, the bright folks affiliated with RedHat
figured out a way to track all the pieces used in building an
application right down to the version numbers.

Great idea! It makes it possible to determine whether package foo.2 will
run reliably or not on your system.

Ah, but what about when you run into "dependency hell". That is not a
fault of the package management system. That is a fault caused by two
things: the end user is mostly to blame for trying to install non-distro
specific binaries (so Fred the Dufus is annoyed because he can't install
a "game" he found on the web written by Larry the Cable Guy using
Mandrake onto his souped up hot rod Fedora box) and the second error is
the developer who is releasing code that was packaged with dependencies
so tight no one can use it but him on that one machine.

So what does Fred need to do? He _could_ get the src.rpm and try
rebuilding it himself. But odds are that Fred can't compile an
application from a tarball if it's more complicated than untar,
configure, make, make install. Forget trying to dig through the spec
file and fix the lib dependencies to be a bit more open than
libfoo-0.02.0.01-beta3. He would have to dig out the tarball from the
src.rpm file and compile it by hand, verify that it work with _his_ libs
and then adjust and repackage and rebuild from the modified src.rpm and
_then_ install.

Don't even ask about Fred digging up an updated lib off the web!

So some other really bright folks figured out that yum was a good next
step. It will look through posted, public repositories and find all the
missing bits for Fred the Dufus.

But to _USE_ yum one must set up a few config files that data about the
repositories. Well, the bright folks at the repositories wrote rpm files
for their repo data. So now Fred can happily yum away into the night
downloading enough stuff to keep is updates churning forever.

So why does this not happen with Debian? They have a web-based package
management system. Ah! But they don't have a multitude of apt-get repos
like the redhat/fedora stuff does. There are official debs and pretty
much that's it. There are LOT'S of them but there is little outside that
process (well, except for ubuntu and friends and even it uses the main
debs repos.). The repo count for rpm stuff is large and growing. I'm not
talking about mirrors, I'm talking about repos that carry things others
do not.


So the final thought on the frustration of rpms vs debs and people not
knowing how to use yum is this:

If you go to the parts store to get a fuel pump for your ford truck,
would you try and put in one for a toyota because it was in stock and on
sale and the one you need was on backorder? Would you try a fuel pump
from a different year ford truck?

Would you complain about the box the fuel pump came in when you get the
wrong part and it won't fit?
-- 
James P. Kinney III          
CEO & Director of Engineering 
Local Net Solutions,LLC        
770-493-8244                    
http://www.localnetsolutions.com

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part