Depencency Database

Linux From Scratch does have some manner of "dependency database" although its form does not lend itself to making queries. The information is stored in xml files, xsl files, and supporting files from which the "book" can be rendered and from which the "blfs-tool" can solve dependencies and create build code.

A less esoteric depency database could prove to be very useful.

I have a work in progress for a flat-file database DEPS_PLAIN_DB with scripts to query it.
Each line of this flat-file dependency database begins with a package from the BLFS BOOK. The required and recommended dependencies (if any) are listed to the side separated by spaces. The order that the dependecies are listed to the side can have an impact on the order reported.

If I want to know what depends upon gtk+-2, I could say:
srch=gtk+-2
sed -n -e "s/\(^\S*\).*\s\(${srch%-[0-9]*}-[0-9]\S*\)\s*.*/\1/p" DEPS_PLAIN_DB

If I want to know what are the dependencies of gtk+-2, I could say:
srch=gtk+-2
sed -n -e "/^$srch/p" DEPS_PLAIN_DB

The scripts WHILE_TRAK_PLAIN and PLAIN_DEPENDON try to get more complete answers that include the dependencies of dependecies, ... and so on. They also try to take into account what is installed on the system by referencing a TRACKING_DIR so that the information provided is more pertinent. TRACKING_DIR is set to /var/lib/jhalfs/BLFS since that seems to be jhalfs' convention.

The idea of the script WHILE_TRAK_PLAIN is to suggest what packages need to be installed before installing the package being queried about.

The idea of the the script PLAIN_DEPENDON is to suggest what packages may be endangered if the package being queried about is deleted.

Example usage and output of WHILE_TRAK_PLAIN:
sh WHILE_TRAK_PLAIN bluefish
:::: bluefish-1.0.7 ::::
xorg7-7.2 --OK
pkgconfig-0.22 --OK
cairo-1.4.14 --OK
glib-2.12.12 --OK
freetype-2.3.4 != freetype-2.3.7
expat-2.0.1 --OK
libxml2-2.6.31 --OK
fontconfig-2.4.2 --OK
pango-1.16.4 --OK
atk-1.18.0 --OK
libtiff-3.8.2 --OK
libjpeg-6b --OK
gtk+-2.10.13 --OK
pcre-7.6 --REQUIRED

Example usage and output of PLAIN_DEPENDON:
sh PLAIN_DEPENDON freetype
Package <depends_upon>
fontconfig-2.4.2 <freetype>
pango-1.16.4 <fontconfig-2.4.2>
gtk+-2.10.13 <pango-1.16.4>
vte-0.16.6 <gtk+-2.10.13>
xfce-4.4.2 <gtk+-2.10.13>
imlib2-1.4.0 <freetype>

The flat-file database DEPS_PLAIN_DB is not perfect. One problem arises from the way dependencies are listed in the BLFS BOOK as a choice of one or more options. Examples of this are pango, fontconfig, dbus, and wireshark. However, the flat-file database can be edited to resolve these things, or to add other entries not mentioned in the BLFS BOOK.

I understand why Linux From Scratch does not provide any such dependency database. The user is expected to proceed to the page in the book for the package that is to be installed. If the package has dependencies, then the user is expected to proceed to the page for each of the dependencies. If that page has dependencies, then the user is expected to keep proceeding in kind until arriving at a page that can be installed. Once satisfying that one, one just returns to where one was and proceed from there. That almost sounds like a description of what the two scripts are trying to do with the database -- To summarize what is going to be involved in an install or an uninstall.

This could possibly lead to some kind of package management assistance somewhere in a range between slackware and crux, although I've only read about those.

**********************************************
Below is nothing but the gory details of an attempt to produce such a dependency database. There probably isn't any interesting stuff in the rest of this post below.
**********************************************

Construction of the dependency database entirely by hand was abandoned because doing so is tiresome by reason of length, slowness, or dullness; boring. In hindsight, that might have been the quickest and easiest way to do it.

Instead, I set up the blfs-tool (blfs_root) mentioned elsewhere and began wrestling with with what looked like pure hacker code to me. I found some bits and pieces that did something interesting and put them into a script called WHAT_PACKAGES. I kept hammering at WHAT_PACKAGES until it could list out all the packages from the BLFS BOOK with their version and recommended dependencies. However, I couldn't figure out how to get it to include the versions of the dependencies. That certainly would require more advanced training with xsltproc, xmllint, xsl, and xml than I possess.

Finally, this command produced output that seemed to be close enough to work with and I saved the output to a file called FOO_ALLDEPS:

sh WHAT_PACKAGES frombook recommended \
| tee FOO_ALLDEPS

I appended these lines to FOO_ALLDEPS to account for some of the perl modules:
URI 1.35 [1.35]
XML-LibXML 1.63 [0.0.0.0]
XML-NamespaceSupport 1.09 [0.0.0.0]
XML-Parser 2.34 [2.34]
XML-SAX 0.16 [0.0.0.0]
XML-SAX-Expat 0.38 [0.0.0.0]
XML-Simple 2.18 [0.0.0.0]

I found gnome-core.dep, gnome-full.dep, kde-core.dep, and kde-full.dep in ~/blfs_root/libs and used the data in those files to add the dependencies to the corresponding lines in FOO_ALLDEPS. I resorted the data in gnome-core.dep to match the order that I had successfully installed gnome from scratch once.

Here is a diff between the FOO_ALLDEPS produced by WHAT_PACKAGES and the finished version:

*** FOO_ALLDEPS 2008-10-09 09:49:48.000000000 -0400
--- /jhalfs/T_NEW_SCRIPTS/FOO_ALLDEPS 2008-10-10 12:51:37.000000000 -0400
***************
*** 111 ****
! gnome-core 0.0.0 [0.0.0.0]
--- 111 ----
! gnome-core 0.0.0 [0.0.0.0] gnome-pre-install-config ORBit2 libbonobo GConf desktop-file-utils gnome-mime-data gnome-vfs libgnome libgnomecanvas gnome-icon-theme gnome-keyring libgnomeui gtk-engines gnome-themes gnome-doc-utils gnome-desktop gnome-backgrounds gnome-menus gnome-panel gnome-session gnome-terminal gnome-applets eel nautilus control-center yelp gnome-user-docs libgnomekbd libgtop vte gail gnome-vfs-monikers hicolor-icon-theme shared-mime-info gnome-config
***************
*** 115 ****
! gnome-full 0.0.0 [0.0.0.0]
--- 115 ----
! gnome-full 0.0.0 [0.0.0.0] gnome-core orca libgail-gnome java-access-bridge gok gnome-speech gnome-mag at-spi zenity totem sound-juicer nautilus-cd-burner gucharmap gnome-volume-manager gnome-utils gnome-system-monitor gnome-screensaver gnome-netstatus gnome-mount gnome-media gnome-keyring-manager gnome-games gedit gdm gconf-editor gcalctool file-roller evince epiphany eog ekiga bug-buddy system-tools-backends libgnomeprintui libgnomeprint libgnomecups gtksourceview gtkhtml gnome-audio evolution-data-server
***************
*** 200 ****
! kde-core 4.4.2 [0.0.0.0]
--- 200 ----
! kde-core 4.4.2 [0.0.0.0] kdebase kdelibs aRts
***************
*** 203 ****
! kde-full 4.4.2 [0.0.0.0]
--- 203 ----
! kde-full 4.4.2 [0.0.0.0] kde-core kdebindings kdewebdev kdevelop kdesdk kde-i18n kdeaddons kdeartwork kdegames kdetoys kdeaccessibility kdeedu kdeutils kdegraphics kdemultimedia kdepim kdenetwork kdeadmin
***************
*** 328 ****
--- 329,335 ----
+ URI 1.35 [1.35]
+ XML-LibXML 1.63 [0.0.0.0]
+ XML-NamespaceSupport 1.09 [0.0.0.0]
+ XML-Parser 2.34 [2.34]
+ XML-SAX 0.16 [0.0.0.0]
+ XML-SAX-Expat 0.38 [0.0.0.0]
+ XML-Simple 2.18 [0.0.0.0]

Finally, a script that might be called VACUUM_DEPS_VERSION does something like a loop with an inner loop that goes over all the deps and vacuums up the version from the line in FOO_ALLDEPS where the name in the first field matches the dep. On each line, after vacuuming up the version numbers, it sticks a dash between each name and its version on that line. It also makes a translation from some flighty names used in the blfs-xml. The flighty names are things such as GLib, glib2, GTK, gtk2 -- names that do not really exist -- in which version 1 is considered different software than version 2 and confusion could result when asking about "glib" or "gtk+-". However, a tarball would rarely ever use the flighty name.

The ouptput of VACUUM_DEPS_VERSION was then sent to the file DEPS_PLAIN_DB with:
sh VACUUM_DEPS_VERSION | tee DEPS_PLAIN_DB