BLFS-6.4RC1 or any

Agathoklis D. Hatzimanikas a.hatzim at gmail.com
Tue Feb 16 13:21:14 PST 2010


On Tue, Feb 16, at 09:34 Matthew Burgess wrote:
> On Tue, 16 Feb 2010 08:38:51 -0600, Randy McMurchy <randy at linuxfromscratch.org> wrote:
> > Mike McCarty wrote these words on 02/16/10 01:32 CST:
> >> To put it another way, my time is my life.
> > 
> > But you have the time to write 9 paragraphs about why you don't like
> > distros and use BLFS! Pot-Kettle-Black. :-)
> > 
> > BTW, you may never again see a released version of BLFS, I'd take the
> > wise advise you were given and use the development version of BLFS for
> > all that you do concerning BLFS.
> > 
> > And I'm saying this as the lead Editor of the book.
> 
> And as a non-contributory member of the editing team ( :-) ) I would whole-heartedly
> agree with this!  I think that BLFS has simply grown far too big to ever be in a
> completely stable *and* useful state.

The book can't never be considered as stable (for various reasons), but neither of the
Linux distributions can be considered as stable too (for the same reasons - Matthew say
some of the reasons below); except Debian stable.
But the book *was* and it *is* in a useful state (I can't offer opinion about the current
state of Gnome/Kde, as I've never found a use for them).

> Things move so quickly in the open source
> arena that as soon as you freeze something as big as BLFS, by the time it's
> stabilised then the kernel, toolchain, etc. have moved on, offering new features
> that would be useful for at least one of the BLFS packages.

Years ago, I've said that it would be better if we could "shrink" BLFS to absolutely
minimum - just to boot in X - thus allowing BLFS to follow closely the LFS cycle, more
easily.
In fact, I was thinking for an integrated "X" chapter (libs and Xorg) in Lfs, written in
a linear format (like LFS is written).

The rest could be done by the community. Tiny and flexible (with multiply branches)
projects could be born, e.g., kde Book, Audio/Video Book, Programming Book, etc...,
thus allowing us to share the responsibilities to a wider development team.

Now we have a Book with no real target (what we are targeting? LFS stable?
LFS development?); a mixed Book that includes, both updated and outdated
packages.

Anyway and assuming nothing is gonna change, one simple thing that we can do to
improve the situation, is to change the LFS cycle.

The current LFS stable 6.5 comes with gcc-4.4.1 and the next stable (planned for March)
is going to ship again with a point release from the same 4.4 branch (gcc-4.4.3). We didn't
ever shipped with a gcc-4.3 release - as a result, we had thrown away all the work that
had be done in BLFS during last year and a part of 2008 (based in gcc-4.3), when LFS had
decided to jump to gcc-4.4 without to produce a release with gcc-4.3.

Ideally, we could have a gcc-4 branch and then we could produce point releases until the last
point release of gcc. That would allowed BLFS to follow (even with the current status), by
just creating a matched branch with LFS. Then at least we could have an obvious target.
As it is well known, the biggest incompatibilities/breakages, come when the compiler changes
to the next major release. If there is no need (to patch a package) to the first point release
of gcc, quite probably there will be no need for a patch to the last point gcc release, so again
quite probably the instructions could work, even if a package stayed outdated.

But maybe is time to reconsider some things.
We are saying that we are targeting advanced users (although sometimes I think this is an
illusion), but our tools and our methods are really for novice users.
A simple example. 
We are using "patch -Np1 -i ../fix.patch". But the same could be achieved if we
were allowed to use a variable, e.g., $PATCHDIR. Similarly for sources/docs, etc...

Again, and if we're not going to change a thing in the current status, we could use in
the BLFS instructions, "if" statements to check for a gcc version, or a glibc version, or
for a package dependency version, or look to the /etc/lfs-release, and act accordingly, e.g.,
applying a patch or sed, whatever..., that will allow again BLFS to follow. 

And another thing, that we can reconsider (although this discussion fits more
in lfs-dev, so sorry).
Can we break LFS in shorter chapters (at least two)?
The absolutely minimum to build a C library (glibc or eglibc), the linker and
the compiler? That will may allow, people with interest to build around the Linux toolchain
their own stuff, without a need for (let's say vim, Bash, texinfo, tar, ...).
(I'm sure the day that will see, Python Linux, or Ruby Linux, or Lua Linux is not
that far away, but even today that would be quite useful guide/platform for those
who build Linux embedded systems, or for those who want to build a system for a
very specific job).

Anyway as a conclusion and to agree with Matthew and Mike, we are living in the Linux
bloated era and if this is not going to stop, soon or later we'll see a major breakage.
Many habits from other proprietary operating systems invaded into Linux. Wishes and
expectations from vendors are pushing into the Linux ecosystem code, that makes the
life (for those they want a (c)lean system) very hard and complicated.
And everyone seems to following that path. Some they dare to call it evolution though.
And for BLFS that means trouble, so we might need to live with it.

So, I'm not quite opponent with Randy (not to produce another BLFS release) - although
I could see it as possible to make a release, if there was a release manager to take the
responsibility and the burden to get out a release.

But, if both Book maintainers say that there is no need for a BLFS release anymore, then at
least we have to find a workable scheme, so we can give to the developers and users a clear
target and don't leave them in the mist.

> Regards,
> 
> Matt.

Regards,
Agathoklis.



More information about the blfs-support mailing list