Back in June I created a patch that covered the command list through chapter 5.
I was working with ALFS as I went ensuring the quality of the edits. The patch can be found in my directory. http://www.linuxfromscratch.org/~rbaker/ I had yet to even look at the books text. I was only merging the text file project's progress with the current LFS command list. I was making edits beyond chapter 5 but never finished. Losing the reboot actually makes the patch method considerably less painful. I never could decide the bast way to approach the problems inserting another chapter into the book would create using a patch. If you would like help editing the XML I would be happy to help. (I know how much you hate it.) RBaker On Mon, Nov 1, 2010 at 10:22 PM, Robert Connolly <rob...@linuxfromscratch.org> wrote: > Hello. > > My situation has got better and more stable. I have been thinking about hlfs, > and I have an hour a day, or so, that I can put back into it. > > I have been brainstorming, and have a lot of ideas. But first things first. > I'd > like to use the LFS-6.7 book to get HLFS going again. This was discussed a bit > before, but I don't remember very well how the discussion turned out. > > Using the LFS stable book saves the time needed to stabilize the package > versions. This work is already done. Time would be spent more directly on > project goals, instead of duplicating the efforts of LFS. > > I have lost the idea that a reboot is needed. New versions of udev need a > recent kernel version, and almost every distribution includes file system > posix > capabilities, so these issues can be added to the host system requirements > instead of a reboot. > > So that's it for the moment. Just add what worked before to the LFS book, and > go from there. I have some new ideas, like having different configurations > for a > development system, a server, and a client, mainly with networking, but this > can be brought up at a later time. > > I also thought about a problem with using user based package/file management. > Make files don't necessarily fail when there is a permission denied during > install. This is a bit of a problem when installing packages that are outside > of the HLFS book, because the admin would need to read the make output to > check, and this would lead to human error. I'm preferring the Trip unionfs > method, because it would resolve this issue, and still allow non-root to > install packages with no risk of damaging the existing system. It also allows > file permissions to be normalized before they're actually installed, instead > of > after. Just a thought. > > Do any of you have opinions about anything here? > > robert > > -- > http://linuxfromscratch.org/mailman/listinfo/hlfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page > > -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
