> A co-worker and I happened to be talking about different packaging > mechanisms, and what most people really need. What always tends to be a > problem is tracking non-packaged installed tarballs (the old ./configure; > make; make install routine). My co-worker is very technically adept, but > he concedes that he doesn't bother installing from tarballs because they > get lost on the system; removing them becomes a pain. > > This got us thinking to how such installations could be tracked, and it > turns out to be a pretty simple idea that we thought of. Since most > GNU-tool-based tarballs use install(1) to move files into the system, why > not setup a little catch inside of install(1) to record what it's putting > where? [...] > Any comments/ideas on this subject are appreciated.
Your insight that the problem is one of how to clean up after an install or how to remove or how to upgrade is exactly on. After copying files to various places on a system how do you gather them back up again? A method of packaging up these many and diverse files are needed. However it would seem that make is not a good packaging system. It was designed for a different purpose and has been pressed into service to do minimal installations. I believe a better solution is to use a tool specifically designed to do packaging. Either rpm or dpkg are excellent tools for this purpose. I never use 'make install' for a production system. However I do that frequently during development and testing. But for release upon a working system that I expect to keep working I package up the files and install them as a package. This way when I upgrade all of the details are handled transparently by the system, even if I have moved the installation prefix from /usr/local to /usr or /opt or wherever. The overhead of creating a package is small. The return on having created a package is large. > Since most GNU-tool-based tarballs use install(1) to move files into > the system, why not setup a little catch inside of install(1) to > record what it's putting where? Probably it is safe to say that most GNU based tar files are created using automake. The ones that don't are more of the exception than the rule. Therefore in order to really make use of an install enhancement you would have to get the automake team to buy into it. If I recall correctly previous discussion on the automake list has stated that automake is not inclined to do system release level packaging. However, there has been discussion on supporting automatically producing a package file for either rpm or deb. See also http://mail.gnu.org/pipermail/automake/2001-November/009851.html and http://www.gyve.org/~jet/autopack Bob _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
