Re: udev fork

Allin Cottrell wrote:

>>> Pkg X "can use" pkg Y (where Y is something that one might or might not
>>> want to install) is not an argument against requiring pkg X.
>>
>> It is for LFS.  Every user builds every package from source.  That's
>> the purpose of LFS.
>
> I don't see it. "Can use" Y means it doesn't have to use Y: if you're
> building X from scratch and don't have a (pressing) use for whatever pkg
> Y provides, then say --disable-Y when configuring X (or maybe that's not
> even needed, if Y is auto-detected). Not a problem.

The dependency links are a problem.  Theoretically, you can build X 
without Y and then build Y and go back and rebuild X.  One or two times 
is not a big deal, but when the chain gets long, most users don't want 
to repeat the process.  As an extreme example, libreoffice takes almost 
10 hours to build on some systems.  If you leave out something, you 
don't want to do that again.

>>> I'm one who thinks (on the basis of experience with home-rolled
>>> systems), that systemd really is a smarter, faster, more comprehensible,
>>> and more user-manageable way to get a Linux system up and running than
>>> sysvinit plus a big mess of shell scripts.
>>
>> After dealing with LFS users for 10 years, my experience is different.
>> If we were building a binary distro to distribute to users, I might
>> agree with you, but we try to make things easy to understand.  The
>> base LFS system has about 2000 lines of shell scripts.  Compare to
>> about 150K of C code in systemd.  If a script has a problem, there are
>> typically about 5 lines in a start or stop. Plowing through all the C
>> code is a lot more difficult.
>
> OK, opinions may differ on this. But I'm not talking about making a
> distro either, just running a DIY Linux system (not strictly LFS, but
> making grateful use of LFS from time to time).
>
> I've found that the C code of systemd "just works"; the only thing I
> have to worry about is the *.service files, which are easier to manage
> than shell scripts plus the menagerie of shell functions they call. I'm
> no more required to concern myself with systemd's C code that I was with
> sysvinit's C code.

I can see your point, but sysv's init is only one small program.  The 
functions are all in one 800 line file of scripts (with substantial 
comments).

Everything gets installed with one 'make install', but you can look at 
any script with any text tool to see exactly what is happening.  It's 
really quite transparent.

>>> However, I take your point about some of the systemd dependencies,
>>> direct and indirect (even though systemd's configure script has a fair
>>> number of useful --disable-whatever options).
>>
>> They have rejected patches that fix the problem.
>
> That's relevant. Any specifics? Did you have a patch to really disable nls?

http://lists.freedesktop.org/archives/systemd-devel/2012-June/005407.html

   -- Bruce
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html