Future plans for xLFS

··· Mathijs ··· bluescreen303 at gmail.com
Sun Jun 4 14:28:32 PDT 2006


Hello,

I'm normaly just a LFS+BLFS user and don't say much on those lists. I read
most of lfs-dev though.
I have a question of which I'm not sure if this is the right place to ask,
but it felt a bit too much to post to lfs-dev, clfs-dev, hlfs-dev and
such...

My question is about the sub-projects.
It's nice to fork now and then to try some different path, or to do stuff
for a specific task, but sometimes it creates a lot of double-work.

about CLFS,
CLFS can be used to build a "normal" (not cross-compiled) system as well...
most instructions look the same as LFS and as far as I can see there are not
many big differences.
It takes a little longer to compile, but the build-method used is very clean
I think.
What's the point in keeping it separate from normal LFS?
As far as I can see CLFS is almost the same as LFS. LFS takes a little
shortcut (adjusting the toolchain) which CLFS doesn't but wouldn't it be
more efficient to use the CLFS method and just say "this part can be
skipped/shortcutted if you build for the same architecture" ?
I know there are some parts that differ (bootscripts, udev-stuff), where
both teams have different opinions, but isn't it wiser to sort things out at
branch-level instead of project level? just like the alphabetical stuff, and
the udev_update stuff.
Are there any plans to merge CLFS and LFS in the near- or distant future?

about HLFS I have almost the same question.
I know HLFS is a bit different but in a way I would like it like this:

just _ONE_ LFS project, maybe a few branches to test new stuff.
in this one LFS book there will be some instructions or patches that are
architecture/CLFS/HLFS specific...
these should just get a different background-color or surrounding.
This way there isn't any double-work and everything is in one place. Also
for learning this is great. People just building normal LFS will see some
instructions that are HLFS-specific. They might get interested, and
understand why this specific patch/instruction goes at that point in the
book.
Next time they build a system they want to try the HLFS parts.


Sorry for my bad english, and for my absolute lack of technical knowledge
about these issues.
I'm very curious by nature and I want to understand how and why things work
the way they do.
By checking out 3 not-so-different projects I fail to keep a nice overview
of the whole xLFS and what they have in common.

thanks for any answers and keep up the good work

Mathijs Kwik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20060604/70d6b6f0/attachment.html>


More information about the lfs-dev mailing list