On Wednesday 27 February 2008 22:37, TheOldFellow wrote: > ... > > What adding a well researched and well documented PM does to the book > is enhancement of that understanding to include management of the > resulting system, and possibly automation of certain dreary and > repetitive parts of the build. I don't see why it's the death-knell.
Because use-cases with 'packaging' are very different from use-cases 'build from source'. With packages you add yet another level of complexity, that require 'referring' system (+ procedure of recovering of this system, or even recovering to some state). Now, to add new component we have only three steps: 1. configure 2. compile 3. install (all dependences will be resolved or not at least on compile stage). Other things are beyond of this scope. With any packages, you will has: 1. configure 2. compile 3. build package (quazi-install + pre-, post-, etc. scripts; write dependencies from other packages---very non-trivial task) 4. check package installation (with respect to packages depends) 5. check package removing (again, with respect to packages depends) 6. check package upgrade (even here, packages depends should be taken into account) The efforts for maintenance of repository of coherent packages are huge. Complexity and tricks for maintining packages will hide core system functionality, so educational component will wither. And what will be in result? Gentoo #2, just another team? IPCop and Smoothwall are not a big args in my fears: both are 'single' distribution with well-defined tasks. Now the main value of LFS (IMO) is clean system: only functionality. No aspects of system maintenance, right? With packages main weight will be on system maintenance side. Make sense? - ptr -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
