Opened 21 years ago
Last modified 19 years ago
#684 closed defect
Must re-evaluate package order then document the rationale. — at Version 40
Reported by: | Owned by: | Jeremy Huntwork | |
---|---|---|---|
Priority: | high | Milestone: | 6.2 |
Component: | Book | Version: | SVN |
Severity: | normal | Keywords: | ICA alphabetical |
Cc: |
Description (last modified by )
More info in the thread starting at the above URL.
Alphabetize where possible. Be careful of test suites. Check purity iteration effects.
After 5.0 release sometime.
Change History (44)
comment:1 by , 21 years ago
Priority: | lowest → high |
---|
comment:2 by , 21 years ago
Priority: | high → normal |
---|
comment:3 by , 20 years ago
Version: | CVS → SVN |
---|
comment:4 by , 19 years ago
One small data point for this - cross-lfs had relegated iana-etc to near the
end of the build, and had some errors in the perl testsuite (particularly, a few messages about a particular protocol). By restoring iana-etc to where it is in regular lfs, the perl testsuite completes without error.
comment:5 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Updated trunk (r7070). Re-open if you feel --infodir is needed.
comment:6 by , 19 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Aak! I was on the wrong bug! :/
comment:7 by , 19 years ago
I'm currently testing an lfs build with nearly-alphabetical package order right now. Here is what I have so far:
Chapter 5
Ncurses-5.5 Bash-3.0 Bzip2-1.0.3 Coreutils-5.92 Diffutils-2.8.1 Findutils-4.2.25 Gawk-3.1.5 Gettext-0.14.5 Grep-2.5.1a Gzip-1.3.5 M4-1.4.4 Make-3.80 Patch-2.5.4 Perl-5.8.7 Sed-4.1.4 Tar-1.15.1 Texinfo-4.8 Util-linux-2.12r
Chapter 6
Ncurses-5.5 Readline-5.0 Zlib-1.2.3 Autoconf-2.59 Automake-1.9.6 Bash-3.0 Bison-2.1 Bzip2-1.0.3 Coreutils-5.92 Diffutils-2.8.1 E2fsprogs-1.38 File-4.16 Findutils-4.2.25 Flex-2.5.31 GRUB-0.97 Gawk-3.1.5 Gettext-0.14.5 Grep-2.5.1a Groff-1.19.2 Gzip-1.3.5 Hotplug-2004_09_23 IPRoute2-051007 Iana-Etc-2.00 Inetutils-1.4.2 Kbd-1.12 Less-382 Libtool-1.5.20 M4-1.4.4 Make-3.80 Man-1.6b Mktemp-1.5 Module-Init-Tools-3.1 Patch-2.5.4 Perl-5.8.7 Procps-3.2.5 Psmisc-21.6 Sed-4.1.4 Shadow-4.0.12 Sysklogd-1.4.1 Sysvinit-2.86 Tar-1.15.1 Texinfo-4.8 Udev-071 Util-linux-2.12r Vim-6.3
Also, is there any reason that dejagnu is after tcl and expect? Does it require either of them? Same with the toolchain build order in chap. 5, after the adjustment - is there a specific reason why gcc Pass 2 needs to be installed before binutils Pass 2, particularly since both Pass 1 and Chap. 6 build binutils first?
comment:8 by , 19 years ago
I've made a little more progress...
- Autoconf needs Perl (more than just the minimal Perl installed in Chap. 5) so
Perl needs to be among the 1st packages installed.
- The Perl testsuite needs Iana-Etc, so Iana-Etc also needs to be moved up and
should be added to the list of Perl's dependencies.
- Bash's testsuite has hard-wired paths for rm, chmod, and other Coreutils
programs, so Coreutils needs to be moved (back) to the beginning of the list.
I've just built a complete system with this build order, and it seems to be worknig fine so far. Here's the slightly modified build order...
Coreutils-5.92 Iana-Etc-2.00 Ncurses-5.5 Perl-5.8.7 Readline-5.0 Zlib-1.2.3 Autoconf-2.59 Automake-1.9.6 Bash-3.0 Bison-2.1 Bzip2-1.0.3 Diffutils-2.8.1 E2fsprogs-1.38 File-4.16 Findutils-4.2.25 Flex-2.5.31 GRUB-0.97 Gawk-3.1.5 Gettext-0.14.5 Grep-2.5.1a Groff-1.19.2 Gzip-1.3.5 Hotplug-2004_09_23 Inetutils-1.4.2 IPRoute2-051007 Kbd-1.12 Less-382 Libtool-1.5.20 M4-1.4.4 Make-3.80 Man-1.6b Mktemp-1.5 Module-Init-Tools-3.1 Patch-2.5.4 Procps-3.2.5 Psmisc-21.6 Sed-4.1.4 Shadow-4.0.12 Sysklogd-1.4.1 Sysvinit-2.86 Tar-1.15.1 Texinfo-4.8 Udev-071 Util-linux-2.12r Vim-6.3
comment:9 by , 19 years ago
I like this a great deal. Chris did you make any changes to the order of the tool chain packages or the testsuite packages, either in chap. 5 or chap. 6? I'd like to get this into trunk and start playing with it a bit more.
comment:10 by , 19 years ago
No, I made no changes to the toolchain. I did ask a couple questions about the order there (toolchain and testing tools) but didn't change them.
comment:11 by , 19 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
After discussing this briefly with Matt, we'd like to test out your suggested order, Chris. We'll create a new branch from trunk at this point and re-arrange the packages as you've listed, toolchain and testsuite packages will remain as is (with the possible exception of putting dejagnu before tcl and expect, if it builds correctly.)
After the branch is created and the orders adjusted, jhalfs can be used to quickly (in a matter of a day or so) build 3 builds:
1) Trunk as it is now 2) The new branch 3) The new branch built from the new branch
We can then compare the builds and logs to see if any major flaws have arisen from the new build order.
comment:12 by , 19 years ago
Status: | new → assigned |
---|
comment:13 by , 19 years ago
Well, I can save you a little bit of time. Dejagnu won't build before Tcl as it looks for the tclsh program.
comment:14 by , 19 years ago
Thank you, Randy. So all testsuite and toolchain packages will stay as is.
comment:15 by , 19 years ago
(In reply to comment #10)
Well, I can save you a little bit of time. Dejagnu won't build before Tcl as it looks for the tclsh program.
Dejagnu does look for tclsh, but it still builds without it. I don't know if that causes dejagnu to be missing functionality so I'm not sure if it should be done, but it does build and install without tcl.
comment:16 by , 19 years ago
From comment 1:
Alphabetize where possible. Be careful of test suites. Check purity iteration effects.
So, looks like we're OK on parts 1 and 2 from that list. Doing part 3 (i.e. build LFS using Chris' build order, then use that to build another LFS, then compare logs and binaries for differences) should let you know whether or not any of the packages (not just dejagnu as mentioned in comment 12) suffer from any functionality changes.
Looks great so far, though. Thanks for tackling this, Chris!
comment:17 by , 19 years ago
Another issue...in Chapter 6, m4 needs to be moved up (between ncurses and iana-etc) because autoconf creates the "autom4te" script with the location of the m4 binary hard-wired into it. This issue has already been mentioned on the mailing list and accounted for in the alphabetical branch, but I'm mentioning here as well to keep all the info about this in one location.
Also, I think it would be a good idea to list *all* dependencies where build order is important, even the ones that are already fulfilled by packages installed alphabetically. For example...
- bzip2 and gzip must be installed before tar
- ncurses must be installed before readline, which must be installed before bash
- ncurses must be installed before texinfo, util-linux, and inetutils
...and so on. Listing every known dependency would make things much easier should a package be added, removed, or replaced in the future.
comment:18 by , 19 years ago
(In reply to comment #14)
Another issue...in Chapter 6, m4 needs to be moved up (between ncurses and iana-etc) because autoconf creates the "autom4te" script with the location of the m4 binary hard-wired into it.
Similar adjustment has been done for sed. It now comes just after readline early in chapter 6. e2fsprogs and libtool were hard-coding the full path to the sed in /tools into their scripts.
Also, I think it would be a good idea to list *all* dependencies where build order is important, even the ones that are already fulfilled by packages installed alphabetically.
Yes, that is part of the bug that needs to be fixed. Since you've done so much of the initial research on this, I would appreciate any patches to the book's XML (or at least revised text for each package) that you could provide, assuming you've documented this information already.
comment:19 by , 19 years ago
(In reply to comment #15)
(In reply to comment #14)
Another issue...in Chapter 6, m4 needs to be moved up (between ncurses and iana-etc) because autoconf creates the "autom4te" script with the location of the m4 binary hard-wired into it.
Similar adjustment has been done for sed. It now comes just after readline early in chapter 6. e2fsprogs and libtool were hard-coding the full path to the sed in /tools into their scripts.
Also, I think it would be a good idea to list *all* dependencies where build order is important, even the ones that are already fulfilled by packages installed alphabetically.
Yes, that is part of the bug that needs to be fixed. Since you've done so much of the initial research on this, I would appreciate any patches to the book's XML (or at least revised text for each package) that you could provide, assuming you've documented this information already.
I have no idea how to create patches, but I will gladly suggest alternate text for any packages that need it. Although I think all the build order explanations
should go in a single place in the book, maybe adding a new section just for
this (or adding to the "How things are going to be done" section). As for each individual package, the only things that need be changed are the list of what each package "depends on", and I think that could stay as just a simple list of other packages it needs - the complete explanation for what package needs what and in what order can all be put into one section, making it easy for people who just want to follow the book and build a system to skip over that one section if they don't really care about why everything is ordered the way it is. Any other thoughts on how this should be done?
comment:20 by , 19 years ago
(In reply to comment #16)
Although I think all the build order explanations should go in a single place in the book, maybe adding a new section just for this (or adding to the "How things are going to be done" section).
I agree, a single section explaining why things are built in the order they are is preferable. Briefly looking at the book, I think ' 1.1. How to Build an LFS System' is too high-level for this info, and the focus of "5.2. Toolchain Technical Notes" is on the toolchain, rather than general build order issues.
So, perhaps a new section "1.2. Package Build Order"? This could (perhaps should?) point to 5.2 as containing further discussions regarding the order of the toolchain packages.
As for each individual package, the only things that need be changed are the list of what each package "depends on", and I think that could stay as just a simple list of other packages it needs
Agreed.
comment:21 by , 19 years ago
I just realized GRUB isn't listed in alphabetical order (it's the first package listed that starts with a "G") but the sort I did put it first because it's in all-caps. It should be between Groff and gzip.
comment:22 by , 19 years ago
(In reply to comment #18)
I just realized GRUB isn't listed in alphabetical order (it's the first package listed that starts with a "G") but the sort I did put it first because it's in all-caps. It should be between Groff and gzip.
I noticed this too, and was going to change it, but I realized that the LFS book refers to it as GRUB which would indeed put it at the beginning of the list. If this is really the only package that is an acronym, perhaps it should stay where it is. If there are others then perhaps we should move it.
comment:23 by , 19 years ago
OK, here's what I have so far in listing build-order dependencies. Each package has a list of (what I know so far) what packages must be installed before that package, and the reason (if needed...if it's anything other than the obvious "links to libraries")...
Perl:
Iana-Etc (needed for testsuite)
Readline:
Ncurses
Autoconf:
M4 (hard-wires path to m4 binary in some scripts) Perl (needs more than the minimal Perl installed in chap. 5)
Automake:
Autoconf
Bash:
Ncurses Readline
Bison:
M4 (hard-wires path to m4 binary in bison executable)
Diffutils:
Coreutils (hard-wires path to pr program)
File:
Sed (hard-wires path to sed binary)
Findutils:
Coreutils (updatedb script hard-wires path to sort binary)
Inetutils:
Ncurses
Kbd:
Bison Flex
Less:
Ncurses
Libtool:
Sed (hard-wires path to sed binary)
Man:
Bzip2 (path to bzip2 in man.conf) Diffutils (path to CMP in man.conf) Gawk (makewhatis script hard-wires path to awk binary) Gzip (path to gunzip in man.conf) Less (path to PAGER in man.conf)
Module-Init-Tools
Zlib
Procps:
Ncurses
Psmisc:
Ncurses
Shadow:
Sed (several scripts (useradd, userdel, vipw) hard-wire path to sed binary)
Tar:
Bzip2 Gzip
Texinfo:
Ncurses
Util-linux:
Ncurses
Vim:
Ncurses
In addition to the above list of what packages must be built in what order, some packages need additions to the plain list of what they "Depend on"...
Perl - Iana-Etc Bash - Readline Man - Bzip2, Diffutils, Gzip, Less Module-Init-Tools - Zlib Tar - Bzip2, Gzip
Unfortuanately I didn't do complete testing for this because I forgot to run testsuites for most packages. Will start finding what (if any) additional dependencies would be needed for package testsuites to pass whenever I get time to try it...
comment:24 by , 19 years ago
Adding some more...
Bash - need Coreutils (testsuite has location for rm and chmod (possibly others as well) binaries hard-wired into it)
Findutils - needs Coreutils (/bin/echo referred to in the testsuite)
Flex - needs Bison (flex will build without bison, but the testsuite looks for bison and fails without it)
GRUB - needs Ncurses - it will build without ncurses, but probably missing some functionality (though I can't find anything specific about *what* would be different)
Udev - needs Coreutils (testsuite has "/bin/echo"). This isn't all though...without coreutils installed into /usr and /bin, udev's testsuite complains that it "Can't exec 'tree'" and fails 26 tests. Somehow it seems "tree" is in the "echo" binary because symlinking /bin/echo ---> /tools/bin/echo causes mosts of the failing tests to pass...but there are still 3 more failures, also complaining about "tree". So I don't know what else is needed... Well, it seems it's something else in coreutils (I just installed coreutils into /usr and the udev testsuite worked with no failures).
Util-linux - needs zlib
comment:25 by , 19 years ago
(In reply to comment #21)
Udev - needs Coreutils (testsuite has "/bin/echo"). This isn't all though...without coreutils installed into /usr and /bin, udev's testsuite complains that it "Can't exec 'tree'" and fails 26 tests.
When a Udev test fails it tries to run `tree' in order to provide detailed feedback on what the differences are between the expected result and the actual result. As we don't install 'tree' then this then causes the 'Can't exec 'tree'" results, but that's not the actual cause of the test failure.
I assume comment #21 was aimed at helping us improve the accuracy of our dependency lists, as for the most part the deps you mention are resolved by installing in packages in alphabetical order (bash->coreutils, grub->ncurses and util-linux->zlib being the exceptions).
comment:26 by , 19 years ago
(In reply to comment #22)
(In reply to comment #21)
Udev - needs Coreutils (testsuite has "/bin/echo"). This isn't all though...without coreutils installed into /usr and /bin, udev's testsuite complains that it "Can't exec 'tree'" and fails 26 tests.
When a Udev test fails it tries to run `tree' in order to provide detailed feedback on what the differences are between the expected result and the actual result. As we don't install 'tree' then this then causes the 'Can't exec 'tree'" results, but that's not the actual cause of the test failure.
Ahhh, thanks for the clarification.
I assume comment #21 was aimed at helping us improve the accuracy of our dependency lists, as for the most part the deps you mention are resolved by installing in packages in alphabetical order (bash->coreutils, grub->ncurses and util-linux->zlib being the exceptions).
Yeah, the idea is to list *all* dependencies that depend on build order, even if it's "automatically" covered by putting them in alphabetical order. You may notice that comment #20 also lists several package dependencies that are covered by alphabetical order.
comment:27 by , 19 years ago
I am building a system with this order, but moved vim near the beginning (suggestion from Gerard in the mailing lists describing the reason why vim is put near the beginning of Chapter 6), between sed and zlib. It seems to work fine, as all of its dependencies are already fulfilled. The only packages that are built before vim in the existing devel-LFS but not in the alphabetical branch are zlib, mktemp, and findutils, and none of those are listed in vim's list of dependencies.
by , 19 years ago
Attachment: | updatedeps.patch added |
---|
Update the list of installation dependencies for several packages in the book
by , 19 years ago
Attachment: | updatedeps.2.patch added |
---|
Update the list of installation dependencies for several packages in the book
comment:28 by , 19 years ago
attachments.isobsolete: | 0 → 1 |
---|
by , 19 years ago
Attachment: | updatedeps.3.patch added |
---|
Update the list of installation dependencies for many packages in the book
comment:30 by , 19 years ago
attachments.isobsolete: | 0 → 1 |
---|
comment:31 by , 19 years ago
I'm starting to write a new page to be added to the book describing the reasons for the build order, and containing the information about what packages depend on each other to build. Any ideas on what this should look like? A couple possibilities...
- A table...
Column 1-This package... Column 2-Depends On... Column 3-Because...
- nested list, like an outline...
- Bash
- Readline
- Ncurses
- Readline
Anyone have any other thoughts on this?
comment:32 by , 19 years ago
blocked: | → 1682 |
---|
comment:33 by , 19 years ago
Adding a little more dependency information...
Findutils needs DejaGNU (for the testsuite) M4 does NOT need perl (the book currently says it does)
comment:34 by , 19 years ago
Chris, you're knocking this one out! I'll add whatever info I have from the ICA runs tomorrow including the build order currently used. I'm out of time tonight, though.
comment:35 by , 19 years ago
Great work on all the ICA testing Dan! I just have a question...I believe the ICA testing checks whether the LFS system can reproduce itself flawlessly. Has there been any testing done to see if you get the same system starting from different hosts?
comment:36 by , 19 years ago
Great work on all the ICA testing Dan! I just have a question...I believe the ICA testing checks whether the LFS system can reproduce itself flawlessly. Has there been any testing done to see if you get the same system starting from different hosts?
ICA could potentially highlight any errors coming from different hosts, but you'd have to try building from different hosts. Hopefully the Ch.5 in the book works well enough that by the time you get to Ch.6 it's independent of the host, but I don't know. I've never tested whether the end result from 2 different hosts is the same. It would be a time consuming test to set up, but it could be done.
The ICA testing has all been done on anduin, which is LFS SVN-20050109 on an Athlon XP 2100. At home I have a couple partitions set up, one with LFS ~20051006, and one with FC4. The problem is that it's a PIII 500, so it takes a LONG time to build anything. And it's my only box, so I can't just let it run for a couple days. (My girlfriend would kill me.)
If there's another host to use, we could do the test. Preferably a non-LFS host.
comment:37 by , 19 years ago
Found some more dependencies that need to be added...
Bash needs Bash and Texinfo IPRoute2 needs Bison and Coreutils Autoconf needs Texinfo Automake needs Texinfo Diffutils needs Texinfo Gzip needs Texinfo Man needs Groff Make needs Perl (for the testsuite) and Texinfo Mktemp needs Bash Module-Init-Tools needs Gawk (for the testsuite) Tar needs Texinfo Util-Linux needs E2fsprogs
comment:39 by , 19 years ago
I reversed the order to find new dependencies. Here's what I've got so far in addition to the last patch. These are just the show stoppers, i.e. the build crashes without them. The ICA should point out a couple more.
man-db: groff groff: bison (uses yacc)
comment:40 by , 19 years ago
Description: | modified (diff) |
---|---|
Milestone: | → 6.2 |
Downgrading to P3. Would be nice to have fixed in the next release but is not of the utmost importance if it doesn't.