Starting BLFS (Mike McCarty)

Hops Error, Line 21, alcoholi.c from_blfs.10.defermentmullkegmalt at
Thu Feb 4 13:25:57 PST 2010

This is my "semi-auto" dependency tracking:

In brief:

1. autofoo, configure, and blfs book to generate a linear list of
packages (this list does not need to be saved, see step 4)
2. install a package
3. write down what you had to do to install that package
4. save what you wrote down in version control
optional 5. use a packager to create your package and use the
packager's tools to install it

In detail:
-Run autofoo (aclocal, autoconf, automake), and ./ if it is
present in the package I'm building

This will generate a list of things I need to install.

-Run ./configure, without arguments

This will generate another list of things I need to install

-Take the package list to BLFS
-Note the required packages there, and add them to my list
-If there is a circular dependency, I treat it as two packages and
give them two different names (e.g. "package-without-gnutls, package")

This generates a linear dependency list, with a vague notion as to the
configure options I'll need to use with each package

-Run ./configure in the first package in the list, with the options I
want to use

This generates even more packages I need to install

-Repeat all steps as necessary with every package until I successfully
pop everything off the list

And finally, the shining jewel that makes it all work

-Add the instructions I used to compile each package, in order, to a
version control database (I prefer git). These include my ./configure
settings and any flags I had to pass to make, make check, or make
install, or any other wackiness that had to ensue to make things work.

This will also cause a detailed, reusable list of packages and
dependencies to be installed for you. You can read it (if you are
using git) with the following commands
git log
and the more verbose
git log | grep -a5 $package

So delete, modify, or spill coffee on your original list to your
heart's content.

I cannot stress version control too much. Any package management
solution is incomplete without it. No matter what you do with your
computer, eventually you will need to repeat something. Maybe you'll
accidentally delete something you didn't back up. Maybe you'll need to
upgrade something. Maybe you'll want to get rid of something and won't
be 100% sure about other things depending on it. Even if you're using
rpm or pkg-config or what have you to keep track of things, they're
never ever perfect.

You need version control.

I reccomend git or bazaar, as they are designed for human beings that
aren't prescient and occasionally fail to predict things years before
they happen, despite being told ad-hoc "you should have" countless
times by every man, woman, and child on earth with a computer.

I used to add the compiled binaries to git too. Actually, I used to
just keep my entire OS under git and just git reset --hard whenever I
screwed anything up, and started a new archive and burnt the old one
to DVD whenever it got to 4 gigs, every install on any computer was a
commit.  But version control, at the end of the day, will always work
better for source files in ascii text than anything else, and the best
diffing and merging toolset in the world is completely useless with
precompiled binaries. So now I just keep track of sources; you have to
recompile binaries every time you change something anyway. And really,
reinstalling packages is a packager's job, not git's.

That said, I'd also reccomend a package manager. I've had lots of
success with both slackware's tools and checkinstall, and rpm.

The advantage both of those have is that it is easy to locate any file
you have installed, and match it up to a package. With slackware's
tools, it's as simple as grep $filename /var/log/packages/* -l. Tells
you right where it is installed on your system too, if locate and
which are being goofy. Rpm's a little trickier, as you have to keep
your precompiled rpms somewhere, but it's still a simple one-liner.
That's one advantage slack's tools have over rpm. The other is the
total lack of dependency hell (although you can of course pass
--nodeps to rpm -i). Basically, slack's tools are easier to use to
maintain existing packages.

The advantage rpm has over checkinstall is that you will have to
torture makefiles a lot less to use the former than the latter. Either
way you'll eventually have to patch a makefile, but with RPM it's
usually just to add DESTDIR before PREFIX; one line on the outside.
Usually you can just use PREFIX and then create the directory tree in
your fake root and won't even have to do that. RPM's build environment
(SPECS, RPMS, etc) is also really easy to turn into a version control
repository root. The "keeping track of instructions" step I mentioned
earlier is literally as simple as adding the spec file you used to
version control. Basically, rpm will require fewer sacrificed goats
and conversations with voodoo priests than checkinstall when you're
building packages.

If you want the best of both worlds, there's always alien -t.

Incidentally, debian has its purposes too: Ever have a real bear of a
time finding the home page (not the icewalkers or softpedia or
what-have-you) for a package? If you find a debian package, the
copyright file always has the url of the place they got the source
from. Other package managers have the functionality, but debian is the
only one I've found that implements it reliably. I don't like apt as
apt is esperanto for "the seventh seal which leads you to dependency
hell", but I won't bash it more than that.

The big advantage to a package manager, aside from the obvious
uninstall/reinstall goodness, is that you can dissect precompiled
packages that really work on real computers with architectures that
start with i686, and torture their terrible secrets out of them. Alien
is good for this too. No more trolling through ubuntu messageboards
whose advice consists of telling you to use a different distro and
wait for someone else to solve your problem :)

So, again in brief

1. autofoo, configure, and blfs book to generate list of packages
2. install a package
3. write down what you had to do to install that package
4. save what you wrote down in version control
optional 5. use a packager to create your package and use the
packager's tools to install it

Which works more reliably, IMHO, than any other package management
solution out there.

More information about the blfs-support mailing list