[This will be my last post on this subject. I've expressed an opinion, not to disparage, but to encourage technical excellence. I'll reiterate some points in this post and leave it at that.]
Jeremy Utley wrote these words on 02/20/05 19:37 CST: > This, IMHO, is a highly optimistic view. For each upgrade, and some > packages have new releases on a pretty frequent basis, you have to > perform a full build of the package, into a non-standard directory, > measure the build sizes, compare the binaries installed with those on > the current list, then research the function of each new binary, > assuming information is available on what that binary does. Yes, this is what I'm talking about. Doing the job right. If it takes 15 minutes, rather than 5, then hold off on the commit until you have the extra 10 minutes. I'm not talking about the toolchain. I'm talking about all the other packages, that just take a minute or less to build. The toolchain is something that should be documented precisely, as it changes. No exceptions. > Then, you > have to properly edit the XML, validate it, ensure the new XML code > renders into HTML properly, and finally commit it. You have to do this stuff anyway. > Well, lets look at it differently. Lets take, for example, a certain > package that undergoes 10 upgrades thru a LFS release cycle. Assume 10 > minutes for testing a build (without installation), updating the package > version entity, testing rendering, and committing - and this is a highly > optimistic time estimate. We'll also assume an extra 30 minutes for > installing the package to a non-standard directory, validating all > installed binaries/libraries, and researching any new binaries that may > be present in the build. I just did a sample build of syslog-ng into a non-standard dir. Wrote a quick build script that cops the time and disk space. Checked out the installed stuff. Less than 5 minutes. Updating the XML would take a couple minutes more at most. [snip hypothetical stuff about 10 updates through a life cycle] > Holding the upgrade of these parts of the XML is simply a more efficient > use of the editorial staff's time, especially when you consider the fact > that anyone using the development version of LFS would logically be > expected to know how to find out this information for themselves, as > they are experienced LFS builders already. Holding off until release has proved to be ineffective and results in the release of inaccurate technical information in a technical book. These are the facts, and nothing is going to change that. > Of course, if it's that important to you, the LFS editorial staff always > welcomes patches to the book's XML :) I've often thought about it, usually while I'm waiting on a BLFS build to finish. But I took that time instead to prepare the BLFS book for the impending changes to the build times, disk space used, new programs added, etc. going into BLFS. :-) -- Randy rmlinux: [GNU ld version 2.15.91.0.2 20040727] [gcc (GCC) 3.4.1] [GNU C Library 2004-07-01 release version 2.3.4] [Linux 2.6.8.1 i686] 19:58:00 up 15 days, 3:47, 8 users, load average: 0.01, 0.03, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
