On Sun, Mar 13, 2011 at 10:44 PM, DJ Lucas <[email protected]> wrote:
> On 03/14/2011 12:03 AM, Nathan Coulson wrote: > > > > On Sun, Mar 13, 2011 at 9:45 PM, DJ Lucas <[email protected]> wrote: > >> On 03/13/2011 11:39 PM, DJ Lucas wrote: >> > Okay, so I was just thinking...<replaceable><Deity></replaceable> >> > help us! I figure we have at least 6 months, potentially a year until >> > the next major LFS release, and now seems like a pretty good time to >> > explore some of the ideas that have been shelved for previous releases, >> > and even some new ones. Here is a quick list to see if there is any >> > interest. I'll reply to my own post afterward to separate my own >> > suggestions from the initial list. >> > >> > * Package Management - Always causes a good debate. >> > >> > * DESTDIR - Been mentioned several times and actually this is not too >> > disruptive (I did a POC about 3 years ago). >> >> For me, these two go hand in hand. Package Management, historically, has >> always generated a fueled debate. There are many options here including >> conditional processing of the book's sources to allow for various forms >> of package management. I had previously suggested years ago that we move >> the default build instructions to include a very simple DESTDIR style >> installation, with the final installation done manually from the DESTDIR >> target. This method lends itself well to almost all forms of package >> management without the need of choosing a specific package manager. This >> method also gives us the option of pre-processing the book's source code >> for a specific package manager either by conditional logic (as I >> understand the new docbook is capable of), or in a simpler form, using a >> Makefile target to pre-process the book using sed or other standard unix >> tools if the instructions are split into pre-install, build, install, >> and post-install targets. >> > > no comment here, although I've personally preferred less instructions to > more where possible. (DESTDIR is not something I use) . I usually throw > away systems when it's time to upgrade though, or just install newer libs > over the old. > > > > That is part of the problem that I see. We all have our own way of doing > things. This is actually fine, but I can see the benefit of standardizing > some items such as package upgrades in the way of a wiki entry. For > instance, keeping a copy of s-ls, s-rm, s-cp, and s-install around for glibc > updates (these would be statically linked copies of the s- tools) which > hasn't been needed for years I'm told, and in fact I had proven not to long > ago by doing an in-place upgrade of GLibC while Gnome was running. :-) I'm > still weary of doing glibc upgrades like that on a live system, perhaps it > is an unfounded fear, but I did it on a test system just for kicks and had > absolutely no issues. I did do a reboot immediately afterward. > > > > * LSB Compliance - For LFS we are nearly there anyway. >> > >> > * Dynamic boot script - No more static list of links, this kind of ties >> > into LSB Bootscripts, but there are other options. >> > >> Again, these two go hand in hand for me. In the current lfs-bootscripts >> tarball, I've been working on and using exclusively the contrib/lsb-v3 >> boot scripts for over 3 years now. They are an extension of something >> that Nathan Coulson and Alexander Patrakov had started on. These are >> completely lsb-v4 compliant as well and are IMO a huge improvement over >> the current boot scripts. I've been using Dan Nicholson's initd-tools >> package to provide the install_initd and remove_initd programs. Aside >> from the fact that there is no longer any need to maintain a list of >> symlinks for startup order, they add a lot of niceties, including >> boot-logging and conditional startup for trouble-shooting. >> > > > ah, I miss the bootscript days. I'll have to take a look, and find out > what I have been missing out on > > > > Yes, please! Another set of eyes and additional brain power is always > welcome! You should still have commit privs so feel free to help yourself. > The current 'stable' boot scripts are the remnants after we ripped out the > i18n additions. Though they are stable, they still contain a lot of cruft > such as boot_mesg which is largely unneeded. I wound up doing a complete > rewrite of rc and a single conditional source of the configuration files in > lsb-v3. IOW, at the cost of possibly faster conditional logic, they only get > sourced by the script if running outside of rc in the lsb-v3 directory. I > honestly don't remember what the 'stty sane' issue was caused by, but I have > never been able to reproduce it since and saw no reason to source the files > in every single sub-shell. BTW, Dan's initd-tools has moved. He is currently > hosting them in his home directory on freedesktop.org. > http://www.mail-archive.com/[email protected]/msg00492.html something to do w/ delete or backspace turning into ^H, if I recall, I think it also prevent someone from pressing enter when something paused the bootup. Whatever it was, it was 5 years ago... if not longer. > > > * Multi-lib - Shunned previously, but there are many projects that >> > expect this environment. >> >> I just kinda threw that in there. A couple of projects that I use beyond >> BLFS expect that environment now for 64bit builds, specifically AOSP, >> Wine, and VirtualBox, all of which forcefully exclude the official LFS >> as my daily driver now. I've been using the work of the CLFS devs for my >> own daily driver with some heavy modifications to match LFS proper as >> much as possible. >> > > When I designed my own multilib system, I had a few goals > - 32bit was not a essential part of my system. Only reason I have it is > for wine, basically... > - I wanted /lib 64bit. Therefore, I used /lib/32 for 32bit libs (although > /lib32 would probably be a better book choice). [always bugged me that /lib > is normally the 32bit directory, especially since it is the default > installation choice] > - If possible, I would have liked to see multilib avaliable "after" > building lfs, but this is probably not feasable. > - I only install 32bit versions of glibc, zlib, ncurses, utillinux as > they're the only ones I actually needed for my 32bit uses. May be worth > reviewing who would be using 32bit, and what applications it would be > supporting. Multilib in the book would look nicer, if only > glibc/gcc/binutils had multilib tweaks. (Enough to compile 32bit software) > > > Yes, unfortunately, the tool chain packages are not enough to do a real > multi-lib system. For my own purposes, I need a working 32bit tool chain, > 32bit X Libraries and server, and 32bit libs up through java. Most of this > is for Android development. For LFS's purposes, the tool chain is enough > however and pretty much what CLFS covers (this includes PPL, Cloog-PPL, GMP, > MPFR, MPC. ZLib, Binutils, GLibC, and GCC). PERL is a real kicker that > brings in more 32bit libs than the tool chain requirements. I haven't tried > to build a multi-lib without it yet to see if it is needed by my own tools, > but I suspect that a lot uses it. If a user is dabbling in multi-lib, then > they should be able to figure out exactly what they need by using the > existing instructions. This paired with DESTDIR style installations provides > some protection to the user as well. BTW Nathan, I did use your page to > figure out what exactly needed to be changed in the GCC drivers as opposed > to sorting through the CLFS patch. I made changes, but that write-up was > quite helpful. Thanks. > I should finish that writeup someday... There was some change we made to the gcc page that I couldn't quite make work w/ multilib, so I just used the old way. > * EGlibC - Seems like Debian and friends are moving to EGlibc, gives us > > a couple of niceties but nothing major, not sure what other distros are > > doing, but I've seen a lot of mentions of it recently. The work is > > already done by the way, our fellow devs at CLFS already have it covered > > for us. > > Same thing, I've seen lots of mentions of it so I'm throwing out the > feelers. CLFS has already done this and I've used both. I have no real > opinion either way yet. I did not have anything more than minor issues > making GLibC proper conform to my expectations (/lib -> lib64/, /usr/lib > -> /usr/lib64, /lib32, and /usr/lib32). > > > * Modular *.d/ directories - I'm pretty sure this is already covered in > > another thread, but it should be done by default where possible. > > > > As mentioned elsewhere recently, this gives a lot of options, and in > fact are required by a few packages in BLFS. I see absolutely no reason > to omit this as the default using the instructions currently in BLFS as > a guideline for strict conformance. > using .d folders has made scripted builds much nicer, and It seems tidier to me. Yes, the end product of modular parts simply looks much cleaner. > > -- DJ Lucas > > > -- > This message has been scanned for viruses and > dangerous content, and is believed to be clean. > > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page > > -- 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
