On Sun, Dec 11, 2005 at 08:55:16PM -0500, Jeremy Huntwork wrote: > > 3) The book will be more technically accurate because it will list the > dependencies of all packages built.
How can it do that? Let's say we've built a toolchain, then built packageA and that package died on depA. You put depA before it, and you know with certainty that packageA requires depA. But now you have to remove both packageA and depA and start with packageB and see if it needs any dependency not covered by the base toolchain. That's like 70 packages you just built and removed iteratively. Eventually you find one that requires depB. Does depB require depA? If not, depA should probably not exist on the system while you iterate through the entire list of packages again, and repeat this ad nauseum. Now, you have a build order that you can say, "These are the required dependencies". Now, you have to read every log created for every package and find the non-required dependencies. Ultimately, this can only be accomplished by reading the source, running strace, reading the configure script, etc, and then parsing all that output and making judgment calls. So the scenario becomes packageA requires depB, but can use depC and depD. If depC is in the book, do we move that up? What about depD, and what if depD is not in the book? Once the decision is made, another complete round of testing is in order. And do we stop at compile-time dependencies or do we include run-time dependencies as well? The moral of this story, ignoring any other comments made in this thread as to feasibility or technical accuracy, is that the work on the alphabetical branch as has been laid out cannot possibly answer item 3 above. Only a vast amount of man hours invested in reading the sources, or an even larger amount of man hours invested in the trial and error of: building, stracing, reading logs, and doing binary analysis can possibly hope to list dependencies with any real accuracy. SBU's are not expected to be 100%. Dependencies must be. Note: none of this is directly related to my opinions as to the alphabetical (or substitute the latest name) branch. I think it is a valid goal, but I do not see it as a needed goal or even recommended goal, and definitely not one that deserves such a high allocation of man hours. Keep in mind the maintenance requirements as well. For a nice case-study, look at the perl failure that seems to have gone unnoticed or at least unfixed for a very long time. I have been diffing my build logs to previous build logs for a few years now because simply reading or even attempting to grep for some unknown keywords in the logs to find problems just takes too long to be a maintainable solution for me. Yet, this perl failure says that either I missed a line of diff output (very likely when reading large amounts of cryptically formatted output) or that this problem has shown in my logs for a long time and thus not in the diff output. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
