On Tue, May 5, 2020 at 6:40 PM Douglas R. Reno via lfs-dev
<lfs-dev@lists.linuxfromscratch.org> wrote:
>
>
> 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

Then why is Util-linux also included in Chapter 5 in the SysVinit
version of LFS? Shouldn't it suffice to only have it be built in
Chapter 6?
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to