On 5/5/20 5:49 AM, 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).
The other problem is that Util-Linux includes some support files (such
as files that go in /usr/lib/tmpfiles.d), that are only installed if
systemd is present. However, systemd itself requires Util-Linux (similar
to eudev I think, it uses it for libmount and libuuid). The way we've
always resolved that is to build Util-Linux in Chapter 5 (previously
there were more packages that required it), and then build systemd, and
then rebuild Util-Linux afterwards.
- Doug
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
