Alright, here's the idea I had.
Background: I work in a NOC that is, of course, 24x7x365. We handle all sorts of stuff.
We were tasked with building up a bunch of servers - Netra T1's - with Solaris 8, and a full-on AMP config (apache, mysql, perl). Well, the guy on the shift before me didn't finish. His ticket entry read something like "built apache and php but php isn't right and neither is apache". Riiight. All this stuff built from source, BTW.
So, anyway, I discovered 2 things: one, it was indeed all screwed up. Two, he has a habit of doing `make && make install && make distclean` because there was no trace of what he passed to `configure`. OK, great; not only do I not know what you're doing, I have no real clue how to not repeat the error.
Or: someone will build a package from source on machine foo, then copy the binary to machine bar. I then am told to log in to machine bar and update the app. Machine foo is always a private box for the engineers and developers, that I have no access to and will never get access to. Well, OK, what options were used? How was it built?
I complain about options a lot, because in my short time here I've learned, no one gets away with `./configure && make && make install`. You need 30 different options to get stuff working.
The Goals: 1. I want to save build and configuration info, in a sensible, automated way. 2. I always want to build from source, always, always. I do not want a binary in a package. Source, source, source. 3. It must be platform-independant, so I can use the same code - completely unaltered - on MacOSX, Linux (all platforms), BSD, and whatever else I can think of.
The Plan: OK, so first, you already have a record of configuration options: configure.status, created by configure. So part one is something like: Add a `make` target, notionall called 'save', that keeps this configuration info somewhere; again, I'm calling it /usr/local/reciepts/PACKAGE-NAME/ until I get a better idea or someone gives me one. Next: capture a list of installed files. This goes in the reciepts dir, too. Generate a stub script, that makes a makefile, with an 'uninstall' target. doing `make uninstall` in this dir removes all the files, natch. Lastly: a stub script that is used in place of configure, or to be exact, uses the saved config data to compile new packages and save configuration. I also *think* that I can use this for automated package builds, better than something like RPM.
The Issues: What if the package gets new options? Well, at least you know how you used to build it...