On Sun, Feb 24, at 10:02 Joe wrote:
>
> Has any thought been given to adopting, for lack of a better term, a
> "ubuntu" approach, i.e., having a Gnome BLFS (GLFS?), KDE BLFS (KLFS?)
> and Server BLFS (SLFS?)? I presume each editor is more comfortable with
> one vs. another and that very few build and use Gnome and KDE together
> on a regular basis. It also seems to me that a server BLFS book would
> be much simpler to keep up to date, since it wouldn't have to include
> any of the X/Gnome/KDE/Multimedia sections. There are of course issues
> of overlap and redundancy, but each "book" would be much more focused,
> and common areas could of course be shared and improved concurrently.
In a inner conversation before two months, I was attempted to throw
the idea for a campaign with a moto like:
"Adopt a package and be the maintainer."
That would help BLFS a lot, since we all are experts in some areas.
[I really liked the patch by Robert about KDE-3.5.9 and not only it
should be applied but it should be committed by Robert himself. But this
Randy's call.]
Another thing that will give BLFS a boost is, if it was decided to support
multilib and other architectures then x86 (quoting Joe Ciccone).
And in my opinion, all the {H,C}LFS developers has to be BLFS developers
too, which sounds very reasonable.
> Later, Alexander E. Patrakov wrote:
>
> >/ IMHO, version numbers and releases are not a thing that one should
> />/ look at. Everyone is going to try the book instructions on the latest
> />/ upstream version./
>
> Is that a realistic expectation? I would've thought that until someone
> has a couple of LFS/BLFS builds under their belt they'd stick with the
> documented version, unless they had a specific interest in a given
> package(s).
This is not only a realistic but it also happens and it should be encouraged;
if not for the benefit of BLFS but to speed upstream development by testing
the latest releases even in a beta form. I would say that in a sense is our
duty as users, because without testing there is no development.
That is how the things work in the world of FOSS.
> On another subject, I appreciate the BLFS style of having the download
> information on the package page vs. the LFS "all packages" approach, but
> I usually like to check the package project home page (provided by LFS)
> and/or a Wikipedia page to help me decide whether I want to build it or
> not, or as a handy reference for associated mailing lists, bug tracking,
> etc. I'll be glad to contribute this information if people think this
> is useful.
A, that would be very useful information in my opinion, but it needs a
lot of work. If you are ready to do that, please *wait* first for what Randy
has to say about that.
--
http://wiki.linuxfromscratch.org/blfs/wiki/Hacking
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
