I'm lucky to have a job that allows me to daydream. I was thinking today, and so here is the resulting rant :-)
I think it would be a good idea to install autoconf, automake, libtool, and probably autogen too, in chapter 5 /tools, to allow us to autoreconf everything in chapter 6 chroot. First, newer autoconf add newer gcc options, like -std=gnu99 to CC. It's not a major thing, but its nice. Second, bugs like the ones in Gawk with LANGINFO_CODESET/LC_MESSAGES can be fixed properly by grabbing the latest configure.ac from gawk-cvs(which doesn't seem to actually exist, but there's a newsgroup), instead of silly hacks to config.h. If these sorts of things are not already fixed upstream, a configure.ac patch is likely to be accepted upstream. Bugs in m4 macros can also be fixed globally by reconfiguring every package... Owl Linux has a couple patches to fix warnings caused by conftest code in autotools. Third (and best), patches to configure.ac and makefile.am are easier to maintain and far more likely to be accepted upstream. Our coreutils-suppress_uptime_kill_su patch is a good example. This patch needs to be re-diffed for every Coreutils release, and it will never end. The best way to not install these programs would be to add a --without-program=uptime,kill,su option to configure.ac. Some Linux distributions use some coreutils' programs and not others, so in the Linux community there must be a dozen hacks to Coreutils to solve basically the same problem. An autoconf/automake macro to disable the build/install of selected programs would allow every distribution to use the same patch. It's better for us because we would have ten times as many testers and auditors using the same patch, its far more likely to be accepted upstream, and the patch would not need to be re-diffed for every new Coreutils release. Autotool patches are also generally smaller and easier for administrators to read/decipher. Furthermore, as I mentioned a while ago it would be nice to have macros for warnings, ssp, fpie, fortify_source, and even mudflap, so they have configure switches to enable or disable them. Again these are far more likely to be accepted upstream if they are configured with autotools, especially now that these features are all in mainline GCC. The same way default_pic -fpic is detected in Glibc, default_ssp can be detected and -fno-stack-protector would be added by --disable-ssp... or -fstack-protector[-all] added by --enable-ssp, or the default to do neither. If accepted upstream, package maintainers (the folks who do the most debugging and auditing) would be more likely to find/fix problems which everyone else may have overlooked. I'm just as guilty of making hacked patches as anyone else. Its a bit more work to add proper macros and scripts for autotools initially, but in the long run its less work. And the last thing I thought about today was a patch policy for HLFS. I think it would be a good idea to make it obligatory for patches to be submitted upstream for review. Package maintainers can either accept, modify, or reject the patch. If it is accepted or modified, more people would be using the patch and it would withstand more testing and review (which is better for everyone). If the patch is rejected but still added to HLFS, we can add a url to the mail thread in the book so there is a documented explanation. Again, I admit I'm as guilty as anyone, but the way our patches are made needs to change. Many of our patches are ugly hacks which have no prayer of ever being accepted, which leaves us to maintain them indefinitely, and leaves the Linux community to have a dozen patches to fix the same problem. I'm tired of participating in this amateur hacking and I'd like to start taking these things a little more seriously. I plan to patch every package to fix compiler warnings, and I want to get off on the right foot. To start, an --enable-werror macro could be added to the autoconf package so its available to every package when they're reconfigured. Its a simple matter of copying the macro to m4/ and including it in aclocal.m4 for submition to package maintainers. The Autoconf macro archive at http://www.gnu.org/software/ac-archive/ has lots good examples. After that, go one package at a time fixing warnings and fixing existing unsuitable patches. Unfortunately this will break HLFS even more than it is already, and put the first stable release even further in the future, however it will make the first stable release better. I can't really see a disadvantage, other than the time consumption. Does anyone have reasons against adding autoconf, automake, and libtool to chapter 5? I'd love to hear comments too, maybe there are issues I have overlooked. robert
pgp7pkgbZDqbW.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
