On 03/14/2011 08:56 PM, Bruce Dubbs wrote: > I've read about 15 messages on this topic and will try to incorporate > the relevant areas in my response. Thanks. > Ken Moffat wrote: >> On Sun, Mar 13, 2011 at 11:39:04PM -0500, 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, > LFS 6.9 is scheduled for September 1st. See the Roadmap in the wiki. Major meaning 7.0. > 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. >>> >> If there is a move from LFS-6 to LFS-7, I expect to see a >> significant change in the build. From what you have listed, >> some of these are *perhaps* major enough to justify it. Personally, >> I have no objection to releases numbered 6.10, 6.11, ... >>
Ken, I probably got ahead of myself thinking that DESTDIR was a shoe-in. It was discussed before with positive results, and hopes were pretty high that it could get done in this cycle. Nothing other than multi-lib would qualify for a major version bump in my original message (IMO). >>> * 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). >>> >> DESTDIR is part of package management. I'll grant that it can >> probably be fitted in without trashing everything else. > I really don't have a problem with adding DESTDIR in Chapter 6. In most > cases I suspect it would only require a few more cp commands and an > explanation in the Package Management section. For BLFS to follow would > be a much larger effort. > Yes, a much bigger undertaking for sure, but that need not be done immediately (or at all for the most part). Once the user has been taught how to deal with the basic PM concepts (breaking the installation down into pre-install, build, install, and post-install tasks), and I still think that DESTDIR is the best possible approach here just to show some of the steps that are hidden by "make install", they can mold BLFS to fit their needs. Remember that LFS is intended to be linear, not open to deviation (unless you are experienced and prepared to deal with the breakage yourself). BLFS on the other hand, is intended, from the start, to be non-linear and is full of choices to be made. >>> * LSB Compliance - For LFS we are nearly there anyway. >>> >> So, since you have raised this, what do you think needs to be done >> that is a major change ? More to the point, should we really care ? >> I don't have any interest in letting people run binaries. >> >>> * Dynamic boot script - No more static list of links, this kind of ties >>> into LSB Bootscripts, but there are other options. >>> >> I don't know what you mean by this ? It's the first time I've heard >> the phrase "dynamic boot script". I hope this isn't anything to do >> with upstart or systemd, what I've seen of those fills me with a >> mixture of horror and disgust ;) > I've looked at this and made some posts about it in 2009. LSB is a > 'trailing' standard and many new capabilities (e.g. Qt4, KDE4, etc are > not adequately addressed in LSB. We already address parts of LSB in > section iv. We also mention building non-wide Ncurses libraries. > > I am not opposed to reworking the bootscripts to be more consistent with > LSB and setting things up to build the boot order into the scripts > instead of the Makefile. Is this enough to relabel LFS to 7.0 instead > of 6.x? Perhaps, but I would lean towards no. Certainly not by itself, no. This is, however, the only task left for the LFS book. Still a few things that would be needed in BLFS. I only envision a major jump in tool chain revisions, or a major change to the build method to warrant an increase in LFS's major version. > That said, the purpose of LSB is to ensure capabilities are in place for > proprietary binaries to be dropped in place. As an open source > advocate, that is not very important to me. > Understood. But there are other advantages to sticking with the standards as much as possible. BLFS can't possibly cover everything, and the closer we are to whatever the set standards of the day, the better functioning the tutorials and HowTo's from outside of LFS. The FHS hasn't been updated in several years, and I suppose it could be argued that an update isn't needed (Xorg belongs in /otp/X.org or /usr now, and it's still a functional guideline). LSB is current, it is being maintained and also being used by most distributions, and takes into account some/most of the FHS except for specific binary placement. In additon, the LSB spec does have some limited usefulness to source builders. Granted, not a lot, but enough that it should at least be considered; initscripts and default cron jobs are case in point. Just one less thing that editors will have to take care of in the future (again, not much of a concern). >>> * Multi-lib - Shunned previously, but there are many projects that >>> expect this environment. >>> >> For people who build from source, which projects *expect* multilib on >> x86_64 ? >> >> I will agree that building a bi-arch desktop (that is, both 32-bit >> and 64-bit Xorg, with some applications as 32-bit and others as >> 64-bit), was a very educational exercise when I did it. That was >> back in the gnome-2.1x days - the real fun was in making some parts >> of gnome 32-bit and others 64-bit). Fun, but pointless. On x64_64, >> modern software runs fine as 64-bit. > This pretty much fits into the same category as above. The only reason > for lib64 to exist is for those proprietary packages that have not been > updated for 64-bit operation. Did you mean /lib containing 32bit libs? /lib64 we don't really have a choice about without more modifications, but the symlink works fine for pure64. > VirtualBox? A system owned by Oracle? I don't think I'm interested. > Besides, there is now a 64-bit version. Does it use 32-bit libraries? Yes, both the source build and binary distribution require both 32bit and 64bit, specifically for the 32bit guest additions on 64bit hosts. What VM software do others use? I'm all for trying something different, unfortunately, VPS doesn't quite fit the bill. > Wine? So you can run proprietary WIN applications? See my comments > about proprietary binaries. > Fortunately, for most tasks, there are many better options available (notice that I didn't say alternatives...I despise the negative connotation of that term), but there are still a few proprietary apps that some of us must be able to run. For the two apps I must run (a customer's in-house application who's last revision was in 1996), I'm personally quite thrilled that I am not forced to dual boot or even have Windows in a VM laying around any longer. OT: Yes, I've been trying for years to get them to go to something off the shelf or web based. $$$ Just ain't gonna happen until I can't fix it any longer, and that day *will* eventually come. I've tried and tried to explain that it will only be more costly when it has to happen on the fly instead of preparing in advance. In fact, that day is finally on the horizon now that XP is no longer available. Yay!...er um...bummer. Is that bad? :-) >>> * 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. >>> >> For a while, eglibc seemed to be dead (no releases). It has become >> alive again, but usually provides very little for i686/x86_64. > What does EGlibC offer that is not in glibc? My understanding is that > it is for embedded systems which are not a target of LFS. > I honestly don't know, that's why I brought it up for discussion. I've seen it being tossed around quite a bit lately. Just don't want any nasty surprises on down the road because we are the only ones left using regular GLibC. >>> * Modular *.d/ directories - I'm pretty sure this is already covered in >>> another thread, but it should be done by default where possible. >>> >> I don't see this as an issue for LFS. What is the problem with >> jsut doing it ? > We already do it in BLFS for /etc/profile.d and programs like apache can > do it with its configuration file. The only potential file I see in LFS > is /etc/ld.so.conf. Personally, I think having a bunch of files that > each add one line (not counting comments) to a configuration file is a > disadvantage, not an advantage. Seeing all the lines in one place is > much easier to understand than in several different files in a different > directory. > Actually, I had intended to suggest that the /etc/profile.d directory be moved to LFS so that it is no longer optional. Also is the /etc/ld.so.d directory, but I guess that is really about it for the LFS target. :-/ I figure if we are going to extend the users knowledge to include managing their systems via simple package management, even if we don't go all the way to a full package manager (which I am absolutely not suggesting!), modularity is a definite plus as it simplifies the automated maintenance tasks of the user's PM of choice should they choose to "go all the way." -- 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
