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 <xry...@mengyan1223.wang>
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
