Building Hell

Hi,
I've seen several things related to "dependency hell" on your archive,
however, I've got a slight variation on dependency hell.  Well, it may
be part of what actually causes dependency hell, but here goes.

Let me state, before I start, that I've used linux for quite a long
time, before modules, when a kernel compile resulted in a monolithic
beast.  So I've compiled my share of packages, and suffered through
dependency hell all through my use of linux.  In fact, for those that
want to put a date to it, I started using linux when you still had to
install from several diskettes... around '94... linux was around before
that, but before that, I'd been using SunOS 4.1.3 and 4.1.4... So I'm no
newbie to general dependency hell.  In fact, it really started with
source distributions.  You'd get some distributions of some great new
software package, you'd explode the source, try to make it, and it would
fail.  You'd find out you needed package Z to complete your install...
and so on and so forth... Sounds like general dependency hell so far.
Well, the thing I find annoying about linux, is that while back then,
this was an "annoying" task, it was feasible.  Now, linux has succeeded
in making this much less feasible.  Why Linux?  Well, mainly because it
was the impetus for the Open Source Movement.  While I love the OSM like
the next geek, the biggest problem is the fact that it *IS* free and
open.  People are free to choose whatever language suits them, choose
whatever libraries are convenient, and build in whatever way they feel
like.  All this freedom sounds good.  And in general, it is good.  The
problem comes when you want or need to muck about in someone else's code
for yourself.  So you get the source distribution.  Its written in a
language you don't use regularly, so you have to download the language.
Then, once the language is downloaded, you find out that the package
still won't run because it depends on some *EXTENSION*.  And this is
where dependency hell ends and "extensionitis" begins.  So, you get the
first extension to the language, you find out it depends on a number of
things, and you get those... more dependency hell...  But, once you get
*THAT* language extension installed, you find out that the language has
*ANOTHER* extension you need for something else you don't use.  Perfect
example is BitPim.  BitPim is written in Python.  Python is a nice
little language.  But if you think you'll be able to run BitPim from the
source with just Python, you're mistaken!  Here's the dependency list
for just the *FIRST* language extension:

	BitPim - Requires wxPython.... 
	wxPython - requires GTK and PyOpenGL
	GTK - requires pango, atk, glib, freetype2 and others
	glib - mercifully compiles mostly on its own
	pango - requires freetype2
	atk - again mercifully compiles mostly on its own.
	PyOpenGL - requires Mesa

Looks like normal dependency hell.. but as I stated, that was just the
*FIRST* language extension.  BitPim ALSO requires you use APSW, a thing
that links python to SQLite.  So why is this more of an annoyance that
dependency hell?  Well, I've now tried to run bp.py NUMEROUS times
without success.  At first, I got unfamiliar errors about finding wx...
What was wx?  How was I to find out?  Fortunately (or unfortunately), I
ran across some stuff about wxPython and figured that must be the wx
that was being referred to.  Once I finally installed wxPython, I tried
running it again.  I found out I had conflicting versions of wxPython in
place.  I finally got rid of one.  Now I'm a bit further, but I need yet
another extension!  

In addition to the above, installing wxPython was no picnic either.  Not
only is there dependency hell, but "build hell" which refers to the
different ways in which people like to package source code.  I was
perfectly happy with makefiles.  I could fix those when they didn't
work.  Then people switched to configure... they seemed okay at first
because they just about always worked.  It was when they broke that I
started to get white-knuckled.  But now, because someone wanted to write
BitPim in Python, its "setup.py"... much less robust that the configure
scripts I must say, and much harder to trace when you can't find out why
the compiler can't find the header files you've just installed.

All of these can be traced back to the "do it the way *YOU* want to do
it" attitude of open source.  It makes for a terrific development
environment because you truly have the freedom to develop anyway you
want.  So if I don't like setup.py, configure, or anything else, I can
stick with makefiles.  But it doesn't allow the users of the software
any freedom at all.  Particularly if they want or need to install from
source instead of from RPM.  They become locked into the developers
world almost immediately.  While I can understand this notion for
libraries (part of the reason dependency hell comes along in the first
place), some of these other languages have extended this notion further
by adding language extensions that link the language to a particular
piece of software.  So now, not only do I have to worry about which
libraries I've got installed, but I have to install additional, full
blown pieces of software that I'll never use except with this one
package.

Finally, before someone flames me for picking on BitPim (I'm not trying
to target any particular software, and I don't even dislike BitPim, but
this one is a great example of everything I've said), try taking a fresh
install of Fedora Core 3 (or any other fresh install for that matter)
and after the installation, download the BitPim source and see if it
runs.  Regardless of whether FC3 is a broken installation (I know some
will feel it is and they'll want me to switch to Gentoo, or GNU/Linux or
something else), this "extensionitis"/"build hell"/"extreme dependency
hell" really needs to end.  It just gets worse with so many supported
languages and new extensions being added to each.  Its almost another
Tower of Babel out there.  All the freedom is great, but no one seems to
want to clean up the mess that's left over in the aftermath of all the
unconstrained freedom.