Configuration management (was: Apt dependency hell)

Ben Scott dragonhawk at gmail.com
Wed Nov 29 14:16:19 EST 2006


On 11/29/06, Tom Buskey <tom at buskey.name> wrote:
>>> Multiple repositories have finally come to Debian.
>>
>> Debian has had them for years :)
>
> I think they've done a better job in the past then RPM based systems.

  That's largely because, for a long time, Debian was the only distro
with any significant usage that was using dpkg/APT.  That, plus the
large package pool (still one of Debian's greatest attractions) meant
that the dependency problems had already been solved.  There was
nothing magic in the tools.

  Now that Ubuntu is getting serious usage, all the Debian zealots are
discovering that, hey, configuration management is not an aspect of
the package management system, but the nature of how software works.

  In contrast to Debian, there have long been several popular distros
using RPM.  Further, RPM didn't have anything like a single popular
dependency solving tool.  There was autorpm, and rpmfind, and up2date,
and yast, and urpmi, and who-knows-what-else.  The lack of a single
tool did mean knowledge didn't carry over from one distro to the next,
which was a real issue for many.  Now, yum is taking over the RPM
world, so that's becoming less and less of an issue.

  However, the fundamental problem of configuration management is
still there.  If I build a package for, say, Fedora Core 6, it's going
to be configured for the libraries, paths, build options, and so on
present for FC6.  If I try and use that package on a CentOS 4 system,
it is almost certain the configuration will be different.  That's not
something yum, APT, or any other dependency manager is going to fix.

  Personally, I see configuration management as one of the toughest
issues facing the IT world.  A big part of the problem is that the
majority of people don't seem to "get it".  It's even worse then
security in that respect.  The idea of a virus deleting their files is
fairly easy for even the PHBs to wrap their heads around.  But trying
to explain why it's a bad thing that Outlook and Exchange expect
different CDO libraries is like teaching quantum physics to a dog.

  This isn't limited to 'doze, either.  True story: At a past LUG
meeting, someone was trying to demonstrate a particular program.  It
was segfaulting.  It turned out that it used a library which was not
versioned (i.e., just libfoo.so, no libfoo.17.so or anything).  That
library had been updated to support something else, so anything linked
against the old version was now fscked.  Time to rebuild the world.
The presentor said they had contacted the author of the library, and
the author stated that they did not see a reason to add versioning
information to the library.

  DLL hell: Now available for Linux!

  Gag.

-- Ben


More information about the gnhlug-discuss mailing list