To-do items

[Greg Schafer]

Hi Guys

Here are some of my random thoughts on getting this project going.

The first thing I want to get happening is a more robust build. We'll
obviously start out with something that looks similar to the current LFS
build and eventually develop it into the proposed reference build that is
mentioned on the goals page. For example, the current LFS build instructions
fall over when (a) coming from virgin RH6.2 and (b) when trying to build
LFS-5.1 from FC2. Those problems are easily hacked around but I'm more
interested in modifying the build procedures to address these issues at
their very core to hopefully shield us from similar problems in the future.
i.e. I want to robustify the build for future-proofness. Hmmm, can you tell
I like inventing new words as I go along :-)

Oh, I better clear up some other points while I'm here also.

I don't want the project to directly compete with LFS. I'm not interested in
developing a "book" as such but rather a collection of web docs that will
eventually form a nice resource for DIY'ers everywhere. Obviously, the
reference build will need to be documented but at this stage I'm not sure
whether to go with an XML source situation a'la LFS or do something else. I
also want to get a FAQ together to explain in a bit more detail why the need
for this project.

My arch is 32 bit x86. I'd love to work on other arches (especially x86-64)
but without access to other hardware then I'm afraid my hands are pretty
much tied because I refuse to endorse anything I cannot test. Other folks
with access to other hardware are of course welcome to discuss and play
around with the builds. What I'm trying to say is that this project will
initially focus on x86, but there's no reason why we can't eventually come
up with per-arch reference builds or whatever. I want to get into cross
builds eventually too.

I'll flesh out and formalise some of the above into the project goals soon.

Anyway, back to the immediate issues. The first cut of the x86 ref' build
will probably be based on Gcc-3.4.1, HJL Binuutils and current Glibc snaps
and use NPTL threads. Ideally, I'd like to just use the latest stable
released tarball of everything but that is not always going to be possible
(e.g. current Glibc situation). Here are some other things to chew on:

 - seeing as we are not LFS there is not much point in referring to Chapter
   5 and Chapter 6. Instead I propose we use some new terms that match the
   actual phase of the overall build. I'm thinking "temptools phase" and
   "chroot phase" as that best describes what we're actually doing IMHO.

 - get rid of the notion of installing to a partition. The overall goal is
   to build a root filesystem which can literally be built and installed
   anywhere (under /mnt, $HOME, where ever). Once built, the root filesystem
   can simply be copied (tar'ed) over to its final destination. Of course,
   installing directly to the final destination partition is always an
   option.

 - lets drop the static link of the pass1 builds. It's definitely not req'd
   and is a diversion from the real goal and is also a potential source of
   failure when what we need is robustness.

 - find a way to get rid of the bothersome "keep binutils build and src dirs
   hanging around" situation. I've hated that since early plfs development
   days but never found a clean alternative. I have some ideas that should
   be implementable in the context of DIY-Linux where we are interested in
   robustness and scriptability and not shackled by the need to keep typos
   and interactive commands to a minimum.

 - address the "must be running a 2.6 kernel to build NPTL enabled Glibc"
   situation. I saw this mentioned on the LFS lists recently but I've
   developed a simple workaround (with caveats of course). All you need is a
   2.6 kernel and a grub boot floppy. Just interrupt the build after the
   Gcc-pass1 then build a non-modular 2.6 kernel and copy the bzImage to
   /tools (a caveat of course is that you must know the hardware of the
   machine in question and not have any vital piece of hardware that relies
   on modules - all you really need is console, kbd, disk, network). Then
   build grub and make a grub boot floppy. Boot the floppy and tell grub to
   load the previously compiled kernel and voila. You can even get fancy and
   create a filesystem on the floppy and put a menu.lst on it if you really
   want. Ancient systems should boot fine but not everything will work 100%.
   It doesn't matter, the system will be functional enough to kick off a
   script and complete a full build. I should document this little procedure
   ASAP. The reason for the non-modular build is that installing new tools
   on the host is forbidden by the project goals of the ref' build. Have I
   put that in the goals docco yet? :-)

Anyhoo, that's enough rambling for now. I'll put some info up soon on
getting the build working from RH6.2. Then I want to get onto the FC2 issue.
Hmmm, broadband and Vmware are becoming vital testing tools for me.

Please feel free to share your thoughts about any of the above or anything
at all :-)

Regards
Greg