[lfs-dev] dbus, systemd, polkit, and consolekit
lfs65 at cruziero.com
Sun May 11 08:45:30 PDT 2014
> Date: Sun, 11 May 2014 09:11:33 -0500
> From: Bruce Dubbs <bruce.dubbs at gmail.com>
> To: LFS Developers Mailinglist <lfs-dev at lists.linuxfromscratch.org>
> Subject: Re: [lfs-dev] dbus, systemd, polkit, and consolekit
> > There should be a fairly high barrier for inclusion of a package in lfs. They
> > shouldn't be added gratuitously, or for flimsy 'reasons', or because it's
> > 'convenient' at the time.
> > Keep it simple. You're (still tending to) adding pointless complexity to LFS.
> Adding simple libraries or a few stand-alone commands is not adding
Even if it were true: that doesn't mean that you just add them.
Otherwise: then add some more; and add some more; and add some more -
there's some fairly innocuous audio libraries that you can add too. Of
course, the central point is relevance: you're adding things that are not
at all necessary- or directly-relevant- enough, to lfs.
> >> We can revisit that
> >> later if there is a huge hue and cry lamenting that.
> > Hmmmm. If you use language like that - that tries to
> > pre-label/pre-characterise feedback - while doing the things like you're
> > proposing to do, or are doing, then you might find you're being worked-around
> > rather than with or through. It's a truism that 'the majority don't complain,
> > they just walk away, or work-around'.
> I'm inclined to leave in acl/attr/libcap. I'm not sure of the others.
> One consideration is to try to keep the systemd version of the book and
> the mainline version as close to each other as possible. As it is now,
> the only differences in packages is to add systemd and dbus and delete
> sysvinit. The bootscripts are different, but could be harmonized.
Sounds like maybe you are intending to be leaving sysd-related materials
in the non-sysd book, in order to make e.g. merges easier with the lfs-sysd
book, to produce a lfs-combined book.
That would be the wrong way to go about it: instead, you'd keep non-sysd
and lfs-sysd each with just their own stuff, and for maint/updating
lfs-combined, you use re-bases; that way, you don't need to keep re-doing
the same merge-related tasks over & over; but it _is_ via re-basing that
you'd do that - and not by having cruft lying around in one or other of
the non-combined projects to try to make them 'look similar enough' to
'make mergings easier'.
Besides, bear in mind that lfs-sysd will jettison anything that's deemed not
needed by sysd; and likewise will add whatever it needs; both of which are
'fair enough' per se, of course. What would you do for non-sysd book then.
There seems to be still the misapprehension that (just now or for foreseeable
future) sysd can be interoperated-with closely with non-sysd stuff. The
recent attempt at lfs-combined, is the latest in a long line of projects
that have tried to interoperate closely with, &/or work-around, sysd,
and had to 'think again': sysd (for now and for at least medium-term
future, at least with the present folks & their backers at the helm)
is _not interested_ in interoperating with
non-sysd stuff - punkt.
You need to keep the two strands - lfs-nix and lfs-sysd - cleanly separated;
and only from those points, attempt any mergings. (Again:) And then
maintain/upgrade the merged-project via re-bases: don't try to pre- 'make
merges easier' by adding cruft artificially to one/both source branches
(lfs-nix/lfs-sysd) so that they 'look similar' to each other.
> -- Bruce
More information about the lfs-dev