To be sure, you and I have different goals we're trying to achieve, which influences how we build systems. When it comes to building the packages, I go very close to the book in most circumstances, but higher-level parts of my process are quite different than the book supposes. While it may be confusing to the first-timer, I think there's some value to discussion of process.
> So ? I agree that if you screwed up the network interface itself > (misnamed, or missing kernel driver) then networking will not work > *after* you have booted until you fix that, I've got a dozen, maybe two, things I've got to have immediately after LFS, but firewall-protected networking comes next. So once I've got networking going I usually shift to building the rest of the system in the system itself--no questions of contamination or kernel support. I admit to being a bit "old-school" and comfortable working/building at a CLI with a couple VTs--though, admittedly a virgin LFS is a bit *too* Spartan for comfort. Generally, GUI comes in the latter half of my build process. > and also I am well-known > for not running testsuites in my own builds (for many desktop > packages I regard the tests as only useful for the maintainer), but Justifiable. > > For my server, running 8.1, I built and tested NetAddr-IP, Net-DNS, > Net-HTTP before booting the new system. No problems with the tests, > they correctly remarked that certain optional deps were not present > and did not run those tests. I'd like the confidence of seeing the tests have run successfully. So with some trepidation, I'll have the network up and router on. > And if somebody wants to download via the host system there is > always the possibility of booting bare LFS, fixing any errors, going > back to chroot, building through to e.g. Xorg (or Wayland, I > suppose), booting the now-BLFS system to check that things work, and > then going back to chroot until the preferred browser etc have been > built (I do that fairly often on builds where I have updated a lot > of packages, gurgling[¹] for fixes in 'links -g' or lynx is not very > productive). I don't know, maybe we're talking about about the same thing, but once I have those essential comfort items built in the chroot, maybe just before building the important networking packages, or just after, I generally abandon the chroot for good. I still have and use the host for other things including research, but there's nothing necessary to completing the build in the GUI or web browser. The paradigm of my development is "KISS", so I prefer to keep confusion to a minimum, so when I have a comfortable system to use, I find the confusion of having the original host still involved is worth avoiding. > > For *your* distro (building the basics on an i7, distributing the > LFS system to older machines, each of which will be used for a > different purpose) I can understand why you do things your way - but > it is by no means the only way to successfully bring up a new system. > > My purpose is to not put people off by saying "you shouldn't do that" > when maybe they can. I thought I was being clear when I said "it's not worth doing" that I was expressing a personal value judgement. > > ĸen > > 1. I think it was tglx (a kernel maintainer) who first used that > phrase, I like it. New to me. But I fear google is more than a number, it's now a verb that's not going away! Like "Zipper" or "Kleenex" the original trademark owner has had it wrested away. -- Paul Rogers [email protected] Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
