Jim Gifford wrote:
We will no longer be doing a chroot, since we are going to be booting into a working Linux with enough tools to build what we need, this could be a plus for those who want a more minimal system and an easy way to get rid of the tools directory.
I have a major problem with this approach being the only one in the book. We are no longer able to build a system remotely. When we brought up anduin, we had (and still have) no physical access to the system. Under the methodology you are proposing, this will no longer be possible.
I don't have a problem with putting this technology into the book, but removing substantial functionality is a mistake.
It could be done, but you'd have to deviate, likely, from what is in the book. If I'm understanding this correctly, if you are for example, building traditional x86 > x86 you could swap out the reboot for a chroot. I suppose that would be the case for any matching arch pair. In fact, unless there is any technical benefit to rebooting into a fresh kernel before chapter 6 on matching arch pairs, I think I'd rather see the book continue to chroot by default and assume that the user is building for the same arch, which would remove some of the pitfalls. The cross build-method would still be there to abstract the tools from the host machine.
Then, for those who need to build from one arch to another, insert instructions on building a kernel and booting with tools on said machine.
I guess I'm throwing this out because I really want to avoid those pitfalls - which will greatly alter the way all the other LFS projects work - Think of how this will affect ALFS and scripted builds in general.
The main purpose I see to build from one arch for another is because you lack the tools to build straight from the target arch. (I'm not talking about the cross-build method in general - I appreciate very much the goal of achieving 'purer' builds and the *ability* to build from one arch to another). However I don't think we should by default have the build set up in a way that assumes a user is building on two archs. If one of the main reasons for this method is lack of proper hosts for building LFS on other archs, I'm anxious to get some cds going for those archs, and would gratefully accpet any help in that field.
Hope these comments don't come as a huge shock to the rest of the devs, but just reading Jim's comments and thinking on how this will affect the shape and direction of LFS and its related projects - I'm thinking maybe we need to give some serious thought to avoiding those pitfalls entirely.
-- Jeremy Huntwork -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
