On Thu, Jan 12, 2012 at 10:50 PM, Nathan Coulson <conat...@gmail.com> wrote: > 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). >
(BTW, I meant to replace the top few paragraphs with the bottom ones. Apologies) > 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 -- 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
