On 03/14/2011 12:03 AM, Nathan Coulson wrote:
On Sun, Mar 13, 2011 at 9:45 PM, DJ Lucas <[email protected]
<mailto:[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.
> * 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.
> * 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
