releases and stuff

Robert Connolly robert at linuxfromscratch.org
Mon Nov 8 17:38:20 PST 2004


None of this is carved in stone, its just what I feel is a good approach.

After uClibc works and there are instructions to chapter 8 I want to release 
it as hlfs-0.1. Replacing "hlfs/downloads/cvs/" with "hlfs/current" and 
"hlfs/releases". hlfs/current will have the book between releases. Each 
(minor or major) release starts with a new change-log. Using the 
major.minor.sub_minor versioning. The sub_minor is only used to fix broken 
things, like a patch version, normally not used. The minor version will 
change as stuff gets added and changed, and is stable enough to build 
properly. There is no limit to the number of minor versions, and the abruptly 
change to 0 when the major version is bumped. The major version would change 
when roadmap goals are met and all bugs are closed. Okay?

Also, I would like to do the chapter 6 build as a non-privileged user. We 
talked about this last year. The couple reasons I like this is because there 
is nothing in the build phase that needs root privleges, and installing as 
non-root would prevent suid programs from being installed. And tar preserves 
ownerships and permissions when root unpacks source, which is almost useless 
except for accidently giving our users write access to our source.

And, as some of you may know, I want a read-only source tree. The LFS gcc 
specs patch won't work with uClibc because the name of the dynamic loader is 
different. This gives me the opportunity to code that patch to use a compile 
time variable to define /tools/lib/ld.so or /lib/ld.so or /lib/ld-uclibc.so 
at configure. The result should work for both LFS and HLFS, with uClibc or 
Glibc, and would allow users to name /tools whatever they like. Assuming that 
goes well, the same sort of thing can be done with the sspspecs and piespecs 
patches. With all that done we can use the same gcc source in every step, 
from chapter 5 pass1 to blfs. I made prototypes for these months ago, 
submited as gcc-3.3.4-ro-* patches, iirc.

The implementation idea I have for the read-only sources is, for 
example, /sources/base is mounted from a 
cdrom. /sources/base/coreutils-5.2.1/obj is a symlink to ../../obj/coreutils 
(which is /sources/obj/coreutils). Some of you might prefer mounting 
to /usr/src, and build in /usr/obj... using the ../../ relative symlink would 
allow that. To use it do 'cd /sources/base/coreutils-5.2.1/obj 
&& ../configure'. This will work with 90-95% of our packages. Even packages 
without configure scripts can work with it. Some won't, like maybe bzip2, but 
bzip2 is such a small package I have a feeling it could be patched to handle 
it. It wouldn't all work right away, but in time it should.

P.S.
uClibc isn't going well yet. Scrt.o has some issues, maybe the bzip2 problem 
is related. It'll be a while yet. Also the piespecs patch has a bug, it 
breaks 'gcc -pie', I know how to fix it but it'll be a couple days.

robert



More information about the hlfs-dev mailing list