[blfs-support] Dependency chain

Bruce Dubbs bruce.dubbs at gmail.com
Tue May 31 18:03:06 PDT 2016

Paul Rogers wrote:
>> (IOW, the real central issue is that the raw dep-logic is, as noted
>> often(-ish), not a simple tree or even a DAG.)
>> rgds, akh
> Thanks.  They don't call it "dependency hell" for nothing.  I spent
> weeks, part time, trying to plan my 7.7 install for the right order of
> things before I started.  I got there, but it still could be improved.
>> I suspect you actually want the reverse: "Packages in the book which
>> can use this package".  I'll tell you now, it ain't going to fly.
> What I was asking about is a "doubly-linked list" as Bruce suggested.
>> I repeat - what we really need is more editors ...
>> and (critically, in the light of the last year) an ability to work
>> with other editors without denigrating them.
> I had a pretty good reputation for calm reason in the face of typical
> flames over on Galaxy Zoo.  My Asperger's means my emotional responses
> are generally subdued.  I could logically explain to overly excited
> newbies that the presence of a SMBH in one galaxy wasn't going to suck
> every other galaxy in sight into its maw.
>> Also, at a minimum the current release of LFS and BLFS.  Having spare
>> time and a fast machine also help.
> Not so much interested in the first, retired but somehow not overendowed
> with the second, and mostly using Conroe E6700's, only one early i7-940
> quad-core "compiling engine" box, so not much of the last qualification.
>> For your problem - start with the applications you want to have, work
>> out their dependencies iteratively until you get back to base LFS.
>> Then come up with a sequence (build order) which suits what you are
>> doing.  And expect to change that order from time to time.
> I do, but in doing that 1) sometimes one needs to know what was
> depending on this package that now may come out, e.g. HAL, and 2) to
> make a choice among, for example, say databases to install, it helps to
> know how many and which other packages it will support, so to minimize
> the "duplication".
>> e.g. I saw a report on the Mesa list that Python3 will be required
> Case in point.  I'd like to avoid the necessity of supporting both 2 &
> 3.  Sure, I *can*, but it's hardly optimum.
>> Note that he's not asking for any information that isn't already in
>> the book - if Firefox can list a dependency on Gtk3, then we know that
>> for Gtk3, Firefox is a package that requires it. I can't see that it's
>> a huge ongoing burden for editors
> So it seemed, from the outside.  But I've worked with the books enough
> to recognize the amount of work that they save me, which must have come
> from somewhere!  ;-)
>> - but it does require a bunch of clever scripting to automatically
>>    generate the reverse-dependencies from the dependencies, and to
>>    incorporate that into the book.
> pio, my package manager, allows me to tag each package with its
> requirements (building and runtime), and I have scripts that convert
> that into a list with forward and backward pointers.  But I don't
> necessarily add all the optional support.
>> And yeah, I agree it would mostly be waste space in the book. I don't
>> see the use-case for it... what's the benefit in looking at Gtk3, and
> Did I demonstrate that above?
>> seeing a list of some dozens of packages that I can build once I've
>> installed that one?
> Not a great example, to be sure.  Let's take the databases though.
> Several places one can choose, then the question is which one can
> support the most other stuff and which are stuck with only one or two--
> how to minimize.
>> I had a similar question as Paul, where I wanted to know which
>> packages depend on a particular package.
> Yay!
>> At the same time, I understand that this becomes too much work for the
>> people working on updating the book and, for what its worth, I also
>> think it is does not add much value in the book.
> I could agree if all one is considering is getting from LFS to an
> enhanced system, the one way trip, and one isn't particularly interested
> in maintenance.  I think it's a special kind of information that is
> mostly useful when it comes to making an optimized (in some sense)
> system and maintaining it.
>> So, I ended up creating a small Python command line utility that could
>> scrap the data from the book and give me such a list.
> I think I'll give it a try.  (Especially since I've just decided to
> rebuild my 7.7 system as 32-bit also.)  Thanks.

If you have the blfs xml sources, you can use grep.  For instance, if you 
want to know what uses imagemagick:

$ grep -r imagemagick *|grep linkend|grep -v ^tmp|grep -v archive
general/sysutils/obex-data-server.xml:      <xref linkend="imagemagick"/> or
multimedia/libdriv/xine-lib.xml:      <xref linkend="imagemagick"/>,
multimedia/libdriv/xine-lib.xml:      built with <xref linkend='ffmpeg'/> 
and <xref linkend='imagemagick'/>.
multimedia/videoutils/transcode.xml:      <xref linkend="imagemagick"/>,
postlfs/editors/emacs.xml:      <xref linkend="imagemagick"/>,
pst/printing/gs.xml:        <xref linkend="imagemagick"/>.
pst/printing/gutenprint.xml:      <xref linkend="imagemagick"/>,
xsoft/other/feh.xml:      <xref linkend="imagemagick"/> (to load 
unsupported formats)
xsoft/other/tigervnc.xml:      <xref linkend="imagemagick"/> and
xsoft/other/inkscape.xml:      <xref linkend="imagemagick"/>,

It may not be real pretty, but it is quick and straight forward.  It could 
be made into a very short script to make it easier.

   -- Bruce

More information about the blfs-support mailing list