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 ./autogen.sh 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. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
