Rally the Troops LFS/BLFS/CLFS/Livecd too

Dan Nicholson dbn.lists at gmail.com
Wed May 3 08:20:49 PDT 2006


Hi again,

Sorry about the previous post.  Slipped onto the send button.

On 4/30/06, Matt Darcy <lfs-list at projecthugo.co.uk> wrote:
>
> 1.) Kernel Headers, yes you knew this was coming but its certainly worth
> talking about, a lots been said on this but its really still unclear of
> direction. I suppose the discussion should center around
> a.) Do we stick with LLH and pray it takes off again

It's dead.  But I agree with Archaic that for LFS-6.2, a stable
release, this tried and true set should be used.

> b.) work with Jim's methods of sanitizing our own headers

I would be willing to go this route.  I also would like to consider
Jürg Billeter's sanitizing script.

http://www.paldo.org/paldo/sources/linux-glibc-headers/linux-glibc-headers-20060329

The reason is that Jürg is a real programmer and he has built a full
beyond BLFS distro with these headers.

> c.) Look at what other distros are doing and try to work with them

This is even more promising.  According to this
(http://lkml.org/lkml/2006/4/26/296) and subsequent posts by David
Woodhouse of RedHat on LKML, there is a real push to get a collective
sanitization effort amongst the distros.  I will be eagerly monitoring
this since these people have infinitely more experience in this area
than I do.

> 2.) Udev -  This again has been a hot topic of many projects, but with
> LFS now dropping hotplug I feel it important ti discuss and clear up a
> few areas
> a.) Udev rules - how complete/incomplete should they be
> b.) which project cover which rules eg; lfs base only, blfs additional,
> clfs base+additional archs devices ? that sort of thing

I'd like to see one major set of rules.  Additional rules that are
package specific (BLFS) or architecture specific (CLFS) I would hope
would be the only separate rules.

This is going to require cooperation among the projects.  I realize
CLFS has a full set of rules as well as LFS.  Let's take a look at
these to form a common set.  Then we can all have the same setup going
forward and CLFS should only have to worry about udev rules for
MIPS-only devices, etc.

> d.) Should we all use the same rules lfs/livecd/cross-lfs/hlfs even ?

Yes.  Unless there is something specific to the project (which would
be dropped into additional rules files), I think we should also see
the same setup in /dev.

> 3.)  users and group creation, I'm reluctant to touch on this again as I
> know its close to a few individuals hearts and a lot of time has been
> put into this, but due to the ude discussion I think its worth at least
> touching upon.

Last week when this issue came up, I made a stink that I didn't want
to see a master list for this purpose.  I still don't want to see it,
but I'd be willing to compromise on it.  This just seems like one of
those areas that will require cross-project cooperation.

I don't feel strongly enough to get into a political war about this,
but here's how I feel.  When you finish the base system, there really
isn't any reason to have more groups than a couple base ones like utmp
and whatever's necessary in the udev rules.  After that, I don't see a
reason to add users and groups until they're necessary.  There's
really no reason to install a mail user and/or group until I actually
have an MTA on my system.

Let's decide something and go forward.

> On a final note, I know this has been said to individuals before, and I
> preach a lot about it, but I'm hoping that with this discussion there is
> a real potential to bring all the projects closer together and more
> "agreed" on the direction the overall project is taking

I feel like this is a good goal.  I personally can say that I'll work
with people as a BLFS editor to make this happen.  Splintering of the
projects doesn't help anyone.

--
Dan



More information about the lfs-dev mailing list