Re: udev fork

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 12 Sep 2012, Bruce Dubbs wrote:

Allin Cottrell wrote:
On Wed, 12 Sep 2012, Bruce Dubbs wrote:

Greg KH wrote:
On Wed, Sep 12, 2012 at 03:56:33PM -0500, Bruce Dubbs wrote:
Greg KH wrote:

What dependencies?  Run time?  Build time?  And why are dependencies
bad?  Do you have no ram in your system for them?

The configure scripts require packages that are not in LFS.

Like what?  Can't you add them?

intltool, glib, gperf, gobject-introspection.

intl needs XML::Parser.  glib needs libffi and python and can use
pcre, attr, d-bus, gamin, and gtk-doc.  gobject-introspection also
needs glib and can use cairo and gtk-doc.  cairo needs libpng, glib,
and pixman and can use fontconfig, gtk+, xorg libraries (and on and on).

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.

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.

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?

Why intltool, for instance? Systemd has a --disable-nls option in its
configure script. But this is in fact just automake fraud; there's
really no way to disable nls (and everything it brings in, including
intltool), so far as I can tell.

That's why we have a hand crafted Makefile. I don't understand why autotools are needed for a package that only has one target architecture.

For my part I like autoconf but consider automake the spawn of Satan, so I'm part-way with you on that. Makefiles that can be read by human beings -- and don't contain 95% irrelevant repetitive numbskull boilerplate -- are certainly my preference.

--
Allin Cottrell
Department of Economics
Wake Forest University
--
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


[Index of Archives]     [Linux Kernel]     [Linux DVB]     [Asterisk Internet PBX]     [DCCP]     [Netdev]     [X.org]     [Util Linux NG]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux