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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
