Hi Akira, On Mon, Jan 20, at 06:27 Akira Urushibata via lfs-dev wrote: > I will talk about LFS on January 25th (Japan time, Saturday) in an > open source event at Osaka.
I'm sure everything went well, and hopefully you will send us some details about the event. > There are a many topics to cover. I find it unfortunate that there > is not enough time to discuss kernel compilation in detail. > > As I stated in an earlier post, a major shortcoming in the LFS Book > is that it says nothing about project management. Building LFS is a > significant project and without basic management skills, one is not > likely to succeed. The main purpose for the book is to demystify and document the workings of an Operating System, and possible through away any fears, which quite logically exist. It covers this basic need for a human being that wants to know and understand. Building an OS it is a composition of individual components of gluing them together to produce an homogeneous usefull system, lets say like building a house (borrowing Xi's Ruoyao phrase in another thread), where the foundation is the kernel so rather important!, though the bricks share equally the same importance. The nice thing about all this, is how one component need the others and how a component can use others too to extend itself. If something is quite that important to understand from this monotony ./configure is that that you can activate or deactivate this extensibility, with the usual configure options, --enable-*, --with-*, --disable-*, --without-*. This is the most fascinating thing in all this procedure if you ask me, though at the same time can be a headache, but both BOOKS are trying hard to document those dependencies and relationships. Now, if someone, wants either to have her/his own OS, or wants to build a new bright OS with some bright ideas, then of course needs to find a way to script the building, because somehow in time at the very least, it will need to rebuild a package, lets say for a security related thing (the BLFS book speaks about this stuff and points to usefull sources btw). It was discussed in the past to enforce a way with some kind of a package managment, by lets say using DESTDIR in the building instructions. My opinion is that PM is also an essential thing to master and understand, especially with regards to dependencies. As an updated package can be a dependency of other packages so it would be wise to rebuild this specific chain, so every package can benefit from the update. So what is this crucial information, that it has to be recorded for a package is: - to which package[s] i depend on - to which package[s] i'm a dependency The plain easier for this, as i remember and i've used for a while, was just a Makefile, that produced an order, like: WebServer: apache apache: apr-util pcre apr-util: apr apr: pcre: %: ; @echo "$@" task-%: ; @: The LFS BOOK reserves a page to explain some of PM techniques, without to go into great details though, so i could agree that perhaps an expansion might be needed. But also there are many many hints, that at the very least can be used as a starting point, for an interest and passionate user to build her own. From experience, everyone builds its own finally, as it isn't that hard and it is quite of fun also. But also there are other package managers that can be work on other systems, like xbps from void or Guix from GNU that uses Guile for configuration. So passion and having fun might be enough. Best, Αγαθοκλής -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
