> So I see you point is to reorder the packages in Chap. 6 to reduce packages in > Chap. 5. But I still believe we shouldn't put many packages to before final > GCC. That may cause ICA failures.
Precisely! And I've managed to compiler everything from start to finish with no errors (didn't run the testing suites). > ICA means Iterative Comparison Analysis. As Pierre said in #4624: > > ICA (Iterative comparison analysis) allows to compare several builds of LFS, > > each build being done with the system built during the previous build. If some > > dependency or action was missing on first built and available on followings, > > it shows up immediately. > > > > Whether lfs should be able to rebuild itself completely identical is maybe not > > necessary, but if the second build is too different from the first, it may be > > a indication of incorrectness. > > > > Leaving priority and severity to normal. It will be adjusted depending on what > > is found. > > > > Note that what we have allows building the whole blfs, so it is unlikely that > > priority and severity go the "high" direction. Thanks for taking the time to explain, it would be interesting to do an ICA on this new order then. > I should try your approach and do an ICA, and see what will happen. But I'm now > busy preparing the problem set for an online programming contest. Maybe I'll > have time to do this on May 20. Please do, it'll be really interesting to see if it works for everyone as well with no problems, and it should make stuff easier for both the learner and the maintainer. Good luck with your contest! Thanks again for your time and effort. Sincerely, Firas Khalil Khana On Tue, May 5, 2020 at 2:57 PM Xi Ruoyao via lfs-dev < [email protected]> wrote: > On 2020-05-05 13:49 +0300, Firas Khalil Khana via lfs-dev wrote: > > @Xi, > > > > Thanks for taking the time to explain everything, much appreciated! > > > > > > > Then it will be stupidly inconvenience typing commands. > > > > It will still get you through until bash is rebuilt again in Chapter 6, > with > > no problems. > > > > That being said, I think Ncurses can't be dropped in Chapter 5 because > Python > > in Chapter 5 depends on it (which is needed to get Chapter 6 Glibc to > build). > > > > > > > There is some circular dependency between bison and gettext so it's > > impossible > > > to build both of them only once. It's #4634. > > I've checked this issue and it isn't related to what I've mentioned. > > I mentioned that the final list in Chapter 5 won't contain Bison, > Gettext and > > Flex, but instead they will be rebuilt early on in Chapter 6 in correct > order > > (Gettext -> Bison -> Flex (-> Bison (Optional for the circular > dependency)), > > so Bison will get to be built before Gettext and in Chapter 6, so #4634 > > shouldn't appear. > > > > > Pierre just added them so Chap. 6 binutils can link to libfl.so. It's > > #4631. > > Again instead of adding more to Chapter 5, just reorder some packages in > > Chapter 6 to be built early on. In the list I've suggested, both Bison > and > > Flex will be built before binutils so I don't see how #4631 will happen. > > > > > To avoid more ICA issues we don't want to move many things too "early". > > I'm afraid I'm not familiar with this term. I couldn't find it in the > > "Acronyms and Terms" appendix as well. You mean breakages? > > > > > > > Your distro your rules. > > I was just pointing out the existence of hostname (from debian), but > keeping > > coreutils the provider for hostname is better and more logical at this > point. > > > > > > > Also #4634. > > Again, 4634 won't happen in the lists I've suggested. There will be no > builds > > of Gettext, Bison and Flex in Chapter 5, and instead they'll be built in > the > > correct order and early on in Chapter 6 (Gettext -> Bison -> Flex (-> > Bison > > for those who want to rebuild Bison again when Flex becomes available)). > > > > > We don't want many packages too be early in Chap. 6. > > Why not? Wouldn't it be better and easier to maintain if there were less > > packages to build, without sacrificing any package but just by simply > > reordering packages in Chapter 6? Not having to deal with cross packages > (like > > Perl in Chapter 5, for example) is something good. > > > > > But we are using glibc. Again, your distro your rules. > > Yes, at this point Python can't be removed from Chapter 5 because it's > needed > > by Glibc in Chapter 6 which is like the third package to be built there. > > > > > We don't want many packages too be early in Chap. 6. > > Again why not? > > > > > Wrong. Systemd or eudev depends on lib{uuid,blkid,mount}.so. > > Why add Util-linux to Chapter 5, instead of reordering Util-linux to be > built > > before eudev in Chapter 6 then? Again as I said, I think you're doing > that to > > avoid #4637 so I won't argue, but it has to do with how these packages > are > > configured (and that's not the point now). > > > > > How to untar xz-5.2.5.tar.xz itself in Chap. 6? > > I apologize for missing that, xz then should remain in Chapter 5, but > the user > > can be instructed to extract this sole package before entering the chroot > > environment by relying on the host's xz. > > > > > It's not "the faster the better". If "the faster the better" we can > just > > cross- > > > compile everything in host, and put them altogether. > > I never said that "the faster the better". A cross compiler can only get > you > > so far, as it's mostly for embedded stuff. Anything more complicated > than that > > would cause stuff from the host to leak in, which is why I think LFS's > > approach (using a separate user, having temporary tools in a chroot > > environment...) is a good way to achieve maximum isolation from the host. > > I was just pointing out that a simple reorder might make things easier, > and > > somewhat faster, and might as well remove some headache to maintainers > at this > > point. > > So I see you point is to reorder the packages in Chap. 6 to reduce > packages in > Chap. 5. But I still believe we shouldn't put many packages to before > final > GCC. That may cause ICA failures. > > ICA means Iterative Comparison Analysis. As Pierre said in #4624: > > > ICA (Iterative comparison analysis) allows to compare several builds of > LFS, > > each build being done with the system built during the previous build. > If some > > dependency or action was missing on first built and available on > followings, > > it shows up immediately. > > > > Whether lfs should be able to rebuild itself completely identical is > maybe not > > necessary, but if the second build is too different from the first, it > may be > > a indication of incorrectness. > > > > Leaving priority and severity to normal. It will be adjusted depending > on what > > is found. > > > > Note that what we have allows building the whole blfs, so it is unlikely > that > > priority and severity go the "high" direction. > > I should try your approach and do an ICA, and see what will happen. But > I'm now > busy preparing the problem set for an online programming contest. Maybe > I'll > have time to do this on May 20. > -- > Xi Ruoyao <[email protected]> > School of Aerospace Science and Technology, Xidian University > > -- > http://lists.linuxfromscratch.org/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page
-- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
