On 11/29/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > Dan Nicholson wrote: > > > I agree with Tushar that this is a good reason for fakeroot. I have > > had the exact situation he's describing before. When your building a > > package and following a known good recipe (a la BLFS), this is > > unlikely, but it happens. It's not pleasant to deal with. Either > > way, I still don't think it belongs in the base LFS book. I'd like to > > see a fully fleshed out hint, though. > > I don't know. If we don't insert it in the book, what's the reason? > Because we're trying to keep LFS simple? Pfft. LFS by nature isn't > simple. I doubt Gerard started the project because he wanted to keep his > personal desktop 'simple'. Uncluttered and clean and minimal, yes, but > the process itself is by no means simple. > > Quite frankly, from the comments I've been reading, most of those who > are opposed to putting this type of info in the book aren't giving > technical reasons. They simply say 'it doesn't belong there, it belongs > in a hint.' And that sounds more like they're just not interested in > change, or progression.
Here's my (not technical) reason for keeping it out of the book. I believe that the LFS book has been intended to be followed with maximum simplicity to have the highest guarantee that the instructions have been followed and first-timers won't end up in lfs-support. Whether this is the right way or not, I'm not sure. There's been a lot of veterans speaking out against this line of thought lately. However, if the book's main intent IS to be a learning experience and provide a high level of success for newbies, I think adding that fakeroot approach adds too much complexity and chances for errors. To see an example of what the fakeroot approach looks like in one of its worst cases, consider coreutils or readline: http://www.diy-linux.org/x86-reference-build/chroot.html#c-coreutils http://www.diy-linux.org/x86-reference-build/chroot.html#c-readline There's a lot of chances for typos there in addition to needing to guarantee a variable is set (unless the LFS book just picks a fakeroot location like it does with /tools). Greg gets away with this by putting right at the beginning that DIY is not for newbies and you should go to LFS if you are. He intends that you'll be scripting the build, not copying and pasting to a terminal. This is probably how 90% of the people in lfs-dev do it anyway, but LFS seems to maintain that its prerequisite is that you have a technical Linux background, not that you have experience building full systems from scratch. This whole thing is up to interpretation, but I believe adding the fakeroot method by default would end up hammering lfs-support. On the other hand, I plan on using it in conjunction with package management. But I've built a couple LFS systems now and feel pretty comfortable debugging the problems that can arise. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
