On Tue, Feb 16, at 09:34 Matthew Burgess wrote: > On Tue, 16 Feb 2010 08:38:51 -0600, Randy McMurchy > <ra...@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. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
