@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.
Thanks again for taking the time to reply to my proposals.
Keep up the great work!
Sincerely,
Firas Khalil Khana
On Tue, May 5, 2020 at 1:12 PM Firas Khalil Khana <firas...@gmail.com>
wrote:
> @Ken,
>
> Thanks for your much appreciated response!
>
> I'm not talking about any particular plans. I'm not changing anything in
> the way LFS is being built.
>
> I'm just removing packages from the temporary tools in Chapter 5 that
> aren't needed in Chapter 6 because they'll
> be built again there.
>
> Regarding which, then are we seriously talking about bloatware when most
> of the stuff used is from GNU? I'm just
> saying that to make things more complete (since LFS uses GNU Glibc, GNU
> coreutils, GNU findutils, GNU diffutils...)
> then why not include GNU which as well as?
>
> Thanks for pointing out that BLFS has a which alternative.
>
> Keep up the great work!
>
> On Mon, May 4, 2020 at 8:39 PM Firas Khalil Khana <firas...@gmail.com>
> wrote:
>
>> Hey there,
>>
>> My name is Firas Khalil Khana, and I'm the creator of glaucus
>> <https://www.glaucuslinux.org/>.
>>
>> I'd like to salute your efforts for keeping this project awesome this
>> whole time! The shear amount of information in a single place like LFS is
>> truly impressive.
>>
>> That being said, I'd like to propose a (somewhat) slight change regarding
>> the amount of packages actually needed in the temporary system (Chapter 5,
>> which I'll be referring to as the chroot environment).
>>
>> I'd also like to propose a reordering of some packages in the basic
>> system software (Chapter 6) to conform with the unneeded packages in the
>> chroot environment.
>>
>> Please keep in mind that these proposals weren't tested with the
>> testing/checking suites.
>>
>> Starting with the first proposal in Chapter 5, and after skipping Tcl,
>> Expect and DejaGNU, we can say:
>> 1- Ncurses can be removed? or is it needed for Chapter 5 Python which in
>> turn is needed for Chapter 6 Glibc? Perhaps it can be removed for those
>> using different C libraries (e.g. musl)?
>>
>> 2- Bash (The chroot environment's shell) can be built without curses
>> support by passing "--without-curses", until it gets rebuilt again in
>> Chapter 6 with curses support.
>>
>> 3- Bison can be removed, and built only once early in Chapter 6 (twice
>> for those who want to satisfy flex).
>>
>> 4- Flex can be removed, and built only once early in Chapter 6 (after
>> bison, and before the second build of bison for those who want to satisfy
>> it).
>>
>> 5- Bzip2 can be removed since we're relying on host tools to decompress
>> needed packages that were downloaded early on (plus it will be built early
>> on in Chapter 6 so no package should require it).
>>
>> 6- I prefer to hostname
>> <https://mirrors.kernel.org/debian/pool/main/h/hostname/hostname_3.23.tar.gz>
>> over
>> coreutils hostname but that's totally optional.
>>
>> 7- which <https://ftpmirror.gnu.org/which/which-2.21.tar.gz> can be
>> added after coreutils (some packages may depend on it in the format of
>> using it inside scripts to fetch available binary versions (gcc with go
>> support, coreutils?, the Linux kernel (for testing?), but it's pretty
>> useful once you're in the chroot environment and in the final system as
>> well).
>>
>> 8- Gettext can be removed and built early on in Chapter 6.
>>
>> 9- Gzip can also be removed since we're relying on host tools to
>> decompress needed packages that were downloaded early on (plus it will be
>> built early on in Chapter 6 so no package should require it).
>>
>> 10- Perl can be completely removed and satisfied early on in Chapter 6
>> before packages that require it.
>>
>> 11- Python can be removed? glibc requires it so it can't be removed, but
>> with other C libraries (e.g. musl) it can be removed and built only when
>> needed in Chapter 6.
>>
>> 12- Texinfo can be removed and built early on in Chapter 6.
>>
>> 13- Util-linux can be removed, but I think certain testing suites require
>> it? Perhaps for those who are sure that the packages have been built
>> correctly it can be removed?
>>
>> 14- Xz can be removed and built early on in Chapter 6 since we're relying
>> on host tools to decompress needed packages that were downloaded early on
>> (plus it will be built early on in Chapter 6 so no package should require
>> it).
>>
>> So we'll end up with the following list of packages for Chapter 5
>> (following DejaGNU):
>> 1- M4
>> 2- Ncurses [Glibc only]
>> 3- Bash
>> 4- Coreutils
>> 5- Diffutils
>> 6- File
>> 7- Findutils
>> 8- Gawk
>> 9- Grep
>> 10- Make
>> 11- Patch
>> 12- Python [Glibc only]
>> 13- Sed
>> 14- Tar
>>
>> Regarding Chapter 6, the packages that we've removed from Chapter 5 and
>> are needed here can be built early on (immediately after adjusting the
>> toolchain, and before Chapter 6 Zlib):
>>
>> 1. GDBM
>> 2. Gperf
>> 3. Perl
>> 4. Texinfo
>> 5. help2man (this can be added to satisfy packages that require it like
>> binutils, libtool, autoconf..., and is better than specifying
>> "MAKEINFO=true")
>> 6. Expat
>> 7. XML::Parser
>> 8. Libtool
>> 9. Autoconf
>> 10. Automake
>> 11. Gettext
>> 12. Bison
>> 13. Ncurses
>> 14. Bash
>>
>> and then continuing from Zlib to the end while removing the packages
>> specified above because they were built beforehand (with the exception of
>> bison for those who want to build it a second time after flex).
>>
>> This can help by greatly reducing the amount of time needed to get the
>> final system working, and should make things for some packages (perl and
>> python) easier since they're only built once in the final system when
>> needed (the final builds should also theoretically be easier because
>> they're native builds now, removing the need to deal with cross builds of
>> these packages especially when using other C libraries (e.g. musl)).
>>
>> This also makes Autotools available early on in Chapter 6 in case running
>> "autoreconf", "./autogen.sh", "./bootstrap.sh"... (whatever scripts were
>> called) was needed (patches that include source modifications usually
>> require that).
>>
>> I'd like to thank you again for all the time and effort you've put in
>> this project.
>>
>> Keep up the great work!
>>
>> Sincerely,
>> Firas Khalil Khana
>>
>>
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
