All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Dubbs <bruce.dubbs@gmail.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev fork
Date: Thu, 13 Sep 2012 00:14:22 +0000	[thread overview]
Message-ID: <5051255E.5040402@gmail.com> (raw)
In-Reply-To: <20120912174951.GA32608@glow>

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'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.

> 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.

> 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.

Our Makefile (udev, gudev, keymap, and gir) is only 674 lines. 
Systemd's configure.ac is 812 lines and is a lot more difficult to 
understand if you are not an autotools wizard.

I'll also note that a complete LFS build and install for (base) udev 
takes about 10 seconds.  Boot time for a typical base LFS system is 8 
seconds.

   -- Bruce



  parent reply	other threads:[~2012-09-13  0:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-12 17:49 udev fork sickmind
2012-09-12 17:51 ` sickmind
2012-09-12 18:05 ` Greg KH
2012-09-12 18:09 ` sickmind
2012-09-12 18:14 ` Greg KH
2012-09-12 18:15 ` sickmind
2012-09-12 18:28 ` Greg KH
2012-09-12 18:33 ` Lucas De Marchi
2012-09-12 20:56 ` Bruce Dubbs
2012-09-12 21:19 ` Greg KH
2012-09-12 21:30 ` sickmind
2012-09-12 22:11 ` Bruce Dubbs
2012-09-12 23:44 ` Allin Cottrell
2012-09-13  0:14 ` Bruce Dubbs [this message]
2012-09-13  0:38 ` Allin Cottrell
2012-09-13  2:29 ` Bruce Dubbs
2012-09-13  2:43 ` Paul Bender

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5051255E.5040402@gmail.com \
    --to=bruce.dubbs@gmail.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.