On Thu, Jan 12, 2012 at 1:32 PM, Bruce Dubbs <bruce.du...@gmail.com> wrote:
> I'd like to discuss the direction of LFS with respect to where upstream
> developers appear to be going.
>
> Currently we use sysvinit and udev as the basis of bringing up LFS. We
> do not use an initd/initramfs or systemd.
>
> http://wiki.debian.org/InitrdReplacementOptions
> http://en.wikipedia.org/wiki/Initrd
>
> http://en.wikipedia.org/wiki/Systemd
> http://0pointer.de/blog/projects/why.html
>
> ----------
>
> There appears appears to be a movement to consolidate /bin and /usr/bin,
> /lib and /usr/lib, and /sbin and /usr/sbin.
>
> https://fedoraproject.org/wiki/Features/UsrMove
>
> ----------
>
> udev is dropping support of module-init-tools for a new package called
> kmod. I was able to build kmod with ./configure --with-xz --with-zlib
> && make && make DESTDIR=/tmp/kmod install. The only files installed are:
>
> /usr/bin/kmod
> /usr/include/libkmod.h
> /usr/lib/libkmod.{la,so,so.1,so.1.2.0}
> /usr/lib/pkgconfig/libkmod.pc
>
> ------------
>
> LFS now provides a good, solid, and relatively simple way of bringing up
> a single system. It does not directly support any of these more complex
> methods. The question is: should LFS add these capabilities?
>
> If we did decide to implement the capability for an initramfs and/or
> systemd, I think we might need a whole new chapter in the book.
>
> One of the major purposes of LFS is to explain how the packages in Linux
> fit together.
>
> Personally, I have mixed feelings. For a lot of situations, our current
> implementation of LFS/BLFS works very well. For a large implementation
> where the requirements are varied and complex, I don't think LFS will
> ever be preferable over a commercial distro.
>
> For the purposes of explanation, what we have works, but if we don't
> change, it will become farther and farther away from what people see in
> other implementations. It is similar to the situation with GRUB. GRUB
> Legacy worked pretty well for most people, but for newer situations,
> GRUB2 was necessary. It is a lot more complex, but complexity seems to
> be the inherent result of increased flexibility and capabilities.
>
> If we don't add things like an initramfs to the book, we will probably
> need to limit what our users can do. For instance, we will probably
> need to require that /usr cannot be on a partition separate from /. In
> the era of TB hard disks, that is probably not a big deal. It's hard to
> find a thumb drive smaller than 16GB any more. Many organizations give
> them away as promotional items.
>
> Any changes we decide to make do not need to be done right away. We are
> scheduled to release LFS 7.1 in about 6 weeks. I definitely would not
> want to make major changes before then.
>
> What do you think?
>
> -- Bruce
Personally, I loved the fact that LFS kept up with the latest &
greatest technologies, while still following existing standards.
(Although sometimes we had others who tested out the bleeding edge
waters). Our move to grub, linux 2.6, udev, grub2, then 64bit was
exciting to follow, and I loved the direction we went.
Saying that, I do not know enough about systemd to consider it. It
depends how much complexity it would add to the book, and what it's
dependencies are. (which will take more then the 10 minutes of
googleing I did trying to judge where I stood). What does it add?
What does it break? What is it's future?
initrd/initramfs always felt more useful for systems that need to
setup an environment before mounting root. Fun to learn, but not
something I would want for my own system. I know we were saying that
udev is expecting the environment setup before we run events (and that
retry is going to be phased out), but I would rather not have to
resort to a initrd/initramfs to set it up.
/usr on a seperate partition, I did like the idea of conforming to
that if there is no cost. (ex:/ if we had to make a complete mess of
the system to make it work, it is not worth it). I doubt this is a
feature many use. The only time I setup such a system was just to
find out how well LFS conformed to that (and that was years ago).
I started when LFS 3.3 came out
LFS is still my favorate operating system, and the distribution I
learned linux on (well, first mandrake [couldn't find xterm], then
slackware [2gb software, never understood what all the pkg's were]).
It gave me a small base OS that I could add onto with the hints. For
the first few years, I never even had XFree86 installed. The terminal
sufficed.
As time went on, BLFS was born. Mozilla brought out their browser,
Xorg forked. More and More opensource software was being refined, and
available for my use. I appreciated how LFS/BLFS were adhering to
standards, and working with upstream as opposed to keeping our own
separate set of patches.
Not only was it a simple basic system, it also had the latest
technologies & packages. Watching linux evolve, when we moved from
linux 2.4 to linux 2.6, the fun when tls came out. Some of the most
interesting changes I have seen were the move from mknod (and the
makedev makefile) to udev, the addition of grub (and later grub2), as
well as the introduction of 64bit.
(I wonder if I am the only one who misses such grand changes...
things seem more stabler these days).
I know I love change, even if it is just for the sake of change.
Still, had a few thoughts about the above
/usr on a seperate partition: In the past when I was more involved in
the bootscripts, I setup my system to ensure this feature worked for
the sole reason that it is part of the standard. I felt that if there
was no cost or complexity in using /usr on a seperate partition, then
there was no reason not to pursue it. If the standards change, then
we should change with them.
initramfs/initrd, I am unsure what that offers for the common user
other then the ability to mount a root filesystem that the kernel
cannot mount itself. I know that udev is expecting this, but I am
less clear on what a initramfs can do that a readonly / can't.
As for systemd, this is normally the type of new technologies I love
to tinker with (although in this case, other then reading many people
grumbling about it, I have not had the time to tinker or even research
it myself). If it will be the new standard accepted by all, and does
not require half of BLFS dragged in, then I would be happy to embrace
it. My questions would be, what does it do? and what does it
require?
One last thing I would like to open up to the floor, the use of
"-B/tools/lib/" in chapter 5.
Would it be possible to look into using something like sysroot for
/tools as opposed to defining CC/AR/RANLIB? It always felt more
complicated then what we need, and I can not make it work for my own
personal LFS (multilib, for 64bit, and 32bit)
I agree with the decision to keep multilib out of LFS (Not needed for
the vast majority of software. Users using closed source, wine, or
odcctools [ld that can target osx] would probably be the main audience
for this), but I would still like it to be an option for LFS users
that wish to pursue this goal.
As an example, we currently build gcc as follows in chapter 5 stage 2
CC="$LFS_TGT-gcc -B/tools/lib/" \
AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib \
../gcc-4.6.2/configure --prefix=/tools \
This approach will not be able to compile a gcc, that could target
32bit and 64bit code without drastic changes to how we isolate /tools
from the host (or at least I could not figure out how to do it)
but if we had something like
../gcc-4.6.2/configure --prefix=/tools --host=$LFS_TGT \
Things look much cleaner, and this could be "adapted" much easier for
those who wish to stray from LFS and add on multilib.
Saying that, I"ve never used sysroot for building LFS before... so
forgive me if I ask the impossible.
http://nathancoulson.com/proj_lfs.php has what I currently use. From
a older version of LFS modified for today's versions (not perfect
either, I hate deviating from upstream.)
--
Nathan Coulson (conathan)
------
Location: British Columbia, Canada
Timezone: PST (-8)
Webpage: http://www.nathancoulson.com
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
