LFS stable releases in general (was Re: [RFC] LFS-6.1.1)

Alexander E. Patrakov patrakov at ums.usu.ru
Mon Oct 10 19:32:27 PDT 2005


Greg Schafer wrote:

> Yes. This whole problem adds even more weight to the theory that labeling
> LFS "releases" with version numbers is not a good idea.

I supported this theory until the errata page appeared. My basis was: 
frozen releases without future bugfixes are not "stable releases", but 
just "supposedly good snapshots".

Back to the original question: I'd be equally happy (as a LiveCD 
maintainer) for both LFS-6.1.1 release and just if someone incorporates 
the fixes from the errata page into the official nALFS profile.

> Forgetting about
> releases altogether would solve a lot of problems. Instead, just run with
> a living, breathing, evolving docco. Once the automated "build directly
> from the XML source" stuff is stabilized, terms such as "stable" and
> "development" start to become less relevant IMHO.

Here I disagree. Please suggest the way how to transition to 
(experimental) the use of udeveventrecorder and initramfs instead of the 
"hotplug" package. To make things simpler for you, the following sort of 
bugs is expected: things that get called from udev rules may want /usr 
to be mounted, but we can't guarantee that. Example of workaround:

http://www.linuxfromscratch.org/blfs/view/svn/multimedia/alsa-utils.html

Here I support the "branch for each new feature" approach which is 
equivalent to "testing/development" split if features come one at a time.

-- 
Alexander E. Patrakov



More information about the lfs-dev mailing list