On Sat, Jul 18, at 10:44 Randy McMurchy wrote: > Matthew Burgess wrote these words on 07/18/09 10:05 CST: > > > The Linux From Scratch community is pleased to announce the release of > > LFS Version 6.5 Release Candidate 1. > > [snip] > > It is our intention to release LFS-6.5 final within 2 weeks. > > Just my opinion, but I think that is too aggressive of a timeline. I > realize that the proposed 6.5 actually *builds*, but has anyone actually > tried using it, in real-life situations?
I tend to agree with Randy although for a different reason. LFS is going to release with a new compiler's branch (gcc-4.4.0), that means BLFS (might be more than five hundred packages) needs a full rebuild. I am taking into account (for my disagreement) that this is also the first minor release from the 4.4 branch. I see that LFS-6.4 had shipped with 4.3.2, although there is a 4.3.3 gcc release, which I would probably be using if I wanted to build a machine in real-life situations or I would wait from a Book like ours that is meant for people who seeks for good practices (and a Book release that ships with the first minor release of a new gcc branch doesn't look like a good practice to me); so the first minor release of a new gcc branch looks too aggressive for a new LFS release. To cover people concerns (that are afraid that LFS might lag behind to package versions), I could bring back an old proposal; we can create a new Book branch with every new gcc branch. That would make BLFS job (maybe) easier because the target it would be clear (we are already two releases behind). To clarify my point, Ken and probably others that don't want or they can't build (for example) 6.5, so they could continue to contribute in development in the BLFS 6.4 branch that means in the gcc 4.3 branch. Another way to solve this problem, it's a combination of branches with a pre-set (reasonable) time-frame, every 8 months for instance or even better in a project like ours, perhaps a release once a year it looks sensible, lets say LFS-2009. In this case we could merge major pieces of BLFS in a huge LFS Book. We can maybe start with a minimal LFS, that means toolchain applications, a compiler, the C library, the linker, the development tools to build the kernel and a shell - I would probably using Dash but it lacks the LINENO variable which it makes it unsuitable for autoconf-generated configure scripts (this is from a post from Eric Blake to the Dash mailing list). Anyway this point to build a minimal LFS, is not that critical as chapter-06 it could be used as it is for now, but for the future a pretty minimal LFS is very attractive, especially for embedded system development; you know is the wave of future, like it or not. For example one could build a system with only the basic toolchain and the Lua language, which is extremely suitable for that kind of job and they (developers) already do it (based on Linux and Lua), but usually the source is closed. And another thing to think about is that now there is a choice for the C library and is calling EGLIBC [1], and Debian [2] and that means Ubuntu is going to ship with EGLIBC as a choice (I am not sure if it will be the main choice). Anyway as I said, we could then merge BLFS packages back to a common Book and we can release it once a year. For BLFS that means we have to make some choices to concentrate. We can't have both KDE and GNOME. But we could continue, maybe even with the current format of the Book, and we can give the chance to more people to contribute to BLFS, as we can treat that Book as a field for development, without any obligation to update to newer versions or without claiming for accuracy. The BLFS main developers could be just mergers, that means they can verify and merge the chosen packages to that big Book with an expected release cycle. And that is important for developers and readers. 1. http://www.eglibc.org/home 2. http://blog.aurel32.net/?p=47 P.S I just read this post from Eric Herman http://linuxfromscratch.org/pipermail/lfs-chat/2009-July/028183.html and I've noticed the link to a work based on Ruby, which is something that needs considering. I find the text - at the minimum - more interesting to read than ours. I was thinking about that same thing some time ago and we've had an exchange with a friend to develop an automated application, lets say a curses application that could be used with split'ed windows, so the user could read the relevant text while building the package at the same time. I was thinking that we could have text for any kind of information that concerns the package. E.g., link to the homepage, to the bug tracker, to the repository, to mailing lists, even links to major bugs, to changelogs and even more to rc file samples and examples of usage. Imagine it like a Gnu-Linux package database (for that specific packages that will go into the main Book). So to finish, if we concentrate to fewer packages, then we can make the pages to look more informational and to help the Linux newcomers to understand the internals in a more deeply way. To look more like a real Book with a complete set of references and so on and all that sort of crazy things that makes development so pleasant. Regards, Agathoklis. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
