releases and stuff
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.
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.
More information about the hlfs-dev