Re: shared library dependency hell

Berto writes:
> 
> See the lead section of this week's Linux Weekly News at
> 
>   http://lwn.net/
> 
> for a story about gnucash's dependency on 60 (!) different
> shared libraries.

I don't know if there will be *an* (singular) Arusha angle,
but (strangely) Matt and I were discussing similar things in
the car today.  We live in a world of
five-Cadence-installs-all-at-once (each measured in GB) --
that's plenty of executables to go shared-lib AWOL (prepared
by the least competent group of release engineers on the
planet).

A simple idea that I like is (given that we know where all
the "golden copies" of all the packages are for all of the
platforms...) to have a nightly cron job that wanders over
all of the executables, runs 'file' and 'ldd', accumulates
what it finds, and reports every program that looks to be in
peril (of not running for shared-lib reasons).

Anyone with better notions?

> Thanks, Jonathan for (apparently) removing the separate
> PyXML requirement.

Um, I don't think he has (regrettably).  What appears to be
the case is: if, when you build Python 2.x, you *happen* to
have the pyexpat (XML) parser sitting around and the install
process *happens* to spot it, then you'll get a Python with
useful XML stuff.  Otherwise, you'll get a Python that does
XML except for that tedious "parsing bit" (i.e. you get a
car that is perfect except that it lacks an engine).  Which
of the two you get happens automagically and silently (I
think)...  I am hard-pressed to imagine what major illegal
pharmaceuticals went into this clever scheme.  Sigh.

Will