[lfs-dev] dbus, systemd, polkit, and consolekit

akhiezer lfs65 at cruziero.com
Sun May 11 06:27:28 PDT 2014

> Date: Sat, 10 May 2014 20:07:18 -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
> Ken Moffat wrote:
> > On Fri, May 09, 2014 at 09:37:37PM -0500, Bruce Dubbs wrote:
> >>
> >> Unless I get some feedback in the next couple of days with solid reasons
> >> that systemd, polkit, and consolekit are important, I am going to replace
> >> systemd with eudev in LFS and minimize recommendations for polkit and
> >> consolekit in BLFS.
> >>
> >   Systemd brought in gperf (for the keymaps - I guess that eudev
> > could use it, if anyone has a need for these), acl, attr, libcap,
> > xml-parser.  Can we look forward to any of these additions returning
> > to BLFS ?
> I was thinking that we should leave those in LFS.

Why. They were brought in only as an integral part of the bringing-in-of-sysd
project: and you're reversing the bringing-in-of-sysd project.

>  We have never 
> advertised it as a minimal system.

So what. Doesn't mean that one just adds packages.

>  Having them in LFS simplifies the 
> requirements sections in BLFS by quite a bit.

What 'requirements sections': d'you mean, the sub-sections on each
package's page; those are not made at all extra-'complex' by having the
info on acl/attr/&c.

And (per b/lfs practice) you essentially throw that info away as/if/when
you move a package from blfs to lfs - because there is the b/lfs practice
that you don't include lfs packages in the 'required/recommended/optional'
sections in blfs package pages: and thus essentially state - even though
it is simply false - that anything in blfs now 'depends' on that package
because that package has now moved to lfs.

What 'rationale' are you going to put in lfs for having those packages
in lfs: that they are not needed for lfs but might be convenient for
blfs. Currently all of the 'Rationale ...' info for those packages, links
more-or-less straight to 'needed for systemd'; or for acl/attr are not given
any real connection to the other packages in lfs, whether on rationale page
(lfs 'preface' section), or dependencies page (in lfs appendix), etc.

(( Btw, possible typo in SVN-20140510, Part IV. Appendices, C. Dependencies :
    Must be installed before: Acli, Libcap
	.	"
s/Acli/Acl/ ? 

Why would such a thing happen: aren't those deps infos auto-generated.

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.

An xml-parser (for just one example) in _LFS_ ? :
Date: Fri, 09 May 2014 21:37:37 -0500
From: Bruce Dubbs <bruce.dubbs at gmail.com>
To: LFS Developers Mailinglist <lfs-dev at linuxfromscratch.org>
Subject: [lfs-dev] dbus, systemd, polkit, and consolekit

Many users come to LFS because they don't want the "bloat" of the 
commercial distros.  I am now willing to return to those roots.

Feedback is welcome.

Keep it simple. You're (still tending to) adding pointless complexity 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 will redo dbus in BLFS however.
>    -- Bruce
> -- 


More information about the lfs-dev mailing list