Re: SLFS book chapter proposals

On Mon, 29 Dec 2003, Archaic wrote:

> On Mon, Dec 29, 2003 at 03:49:24AM -0500, ashes wrote:
> > If it helps, I'm not opposed to following LFS-5.0. It is already stabilized so
> > it would be easier to work with. I don't want to hinder community support for
> > SLFS just to use bleeding edge development (it can be an slfs hint though). I
> > hope this helps resolve one issue.
>
> The big debate is whether to use LFS-5 or current CVS. CVS is a moving
> target, but if we did it all to 5.0 and 5.1 or later is released, we
> have to do all the catching up at one time. Quite frankly, I never
> figured anything would be ready while lfs-5.0 is still current, so my
> vote would be to follow cvs, though I'm not deadset on way or the other.
>
> Opinions?
>
>

 My original understanding was that CVS would be branched, and 5.1 etc
might be released as updates before 6.0 was ready (primarily, package
upgrades).  Meanwhile, I thought 6.0 would happen when somebody decided
kernel 2.6 was good enough.  At the moment, I'm not aware of many
significant changes in CVS, although obviously if somebody plans to
audit every package then each new package version is more work (and we
could easily go through 2 or 3 releases of some of them before 6.0 is
released).

 I guess my gut feeling is that LFS-6 will be a lot like LFS-5, but with
the new thread library, a new glibc, and a 2.6 kernel. ('like' in the
sense of "a lot of the plumbing and foundations have changed, but the
overall appearance is very similar)  I'd like to think that parts of
SLFS can be ready before LFS-5 is obsolete, in the same way as BLFS used
to have a lot of "placemarkers" in it.  The other thing about CVS is
that things can be reverted (remember the fun and games with bison?).
Still feeling my way, I guess SLFS will have to (mostly) be aligned to
LFS-CVS (and BLFS-CVS if we are covering applications), but perhaps with
comments about previous versions of a package, along the lines of
"foo-2.3.4 permits the beagle exploit, you really ought to update to
2.3.5", or "BLFS-5.0 used bar-7.6.23, we are not aware of any security
reasons to upgrade it to bar-8.2.0"

 Perhaps it depends on how much resource we've got for tracking
vulnerabilities in old software. Typically, a vulnerability is fixed by
upgrading to a new release (nice, if it's kde with a new qt on a slow
box), but what about where the new version has reworked configuration
files and options ?  This is where conventional distros can ease the
pain by back-porting fixes.  But somehow, I don't think LFS people will
be into that as a general rule.  Hmm, I've talked myself into _always_
following the CVS books (or at least following the latest working
versions for BLFS) :(

Ken (hoping Gerard will give SLFS a separate list real soon now).
-- 
I'm as free as a bird now, and this bird you cannot chain.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-security
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page