On Tue, May 31, 2016 at 11:20:14PM +1200, Simon Geard wrote: > On Tue, 2016-05-31 at 02:30 +0100, Ken Moffat wrote: > > And now you seem to think it will be trivial for us to initially > > add a list of packages which can use this package, and on subsequent > > edits review that list for things which have dropped out or started > > to use this (arguably, if we did that then additions should be added > > when a package starts to use a dependency iff that dependency has a > > list of packages which can use it.. Also, that list will waste a lot > > of space on the page. > > 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 - 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. > > 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 > seeing a list of some dozens of packages that I can build once I've > installed that one? > > Simon.
I thought I would take a look at trying to extract this information from the xml. The following is what I've come up with, followed by a list of the bugs I've noticed. This should be run in BOOK/ in the svn XML checkout. 1. Clean out the tempdir to avoid possible extra matches : make clean 2. Find the names by which things are called in the XML - some of these are packages, many are not. Exclude archived packages because otherwise those _do_ show in the results : INDEXES=$(find . -name '*.xml' | grep -v archive | xargs grep 'sect1 id=' | cut -d '"' -f2) 3. Find the linkend references for each of these, format to show which item it is for and the filename and again drop archive (maybe a bug in step 2, and this will now drop libarchive), also drop xincludes and introduction. Then sort, and drop duplicate lines (there are quite a lot - again, that implies a buggy approach). for IDX in $INDEXES; do find -name '*.xml' | xargs grep "linkend.*$IDX" | sed "s/\(.*\)/$IDX:\1/" | cut -d ':' -f1,2 ; done | grep -v -e 'archive' -e 'xincludes' -e 'introduction' | sort -u The major problem with this approach is that it does not distinguish where a dependency is optional (for those, an extra configure switch is sometimes necessary to make a package use the dependency). Bugs I have noticed (I'm sure there are more) : 1. asymptote is shown as enabling ghostscript, probably from the note on the gs page which as of 27th May read: The shared library depends on GTK+-2.24.30. It is only used in external programs like asymptote-2.38 and ImageMagick-7.0.1-3. 2. balsa is shown as enabling ./networking/mailnews/other.xml which is an index page, similarly bind is shown as enabling itself (./server/major/bind.xml) 3. multiple entries for some things, e.g. bind has two entries for mercurial, subversion, ldns, nfs-utils - that is why I added -u to the sort. 4. 'ed' shows up as enabling many things, most (maybe all) are bogus. Similarly 'at'. 5. firefox supposedly enables python2 and seamonkey - I suspect that is from the Note that openssl needs to be installed before Python2. And arguably the bootscripts could be grepped out - the (specific) script does indeed enable the package at runtime in a sysvinit system. This is just offered so that people can play with scripting if they really really want to - I repeat that knowing what you want to build, or what you now wish to try out, and working backwards through the deps is the only supported method of sorting out hte dependencies. ĸen -- I had to walk fifteen miles to school, barefoot in the snow. Uphill both ways. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
