[OE-core] [PATCH 1/2] util-linux: disable systemd

Richard Purdie rpurdie at rpsys.net
Tue Feb 24 23:32:03 UTC 2015


On Tue, 2015-02-24 at 12:48 -0800, Khem Raj wrote:
> > On Feb 24, 2015, at 10:07 AM, Ross Burton <ross.burton at intel.com> wrote:
> > 
> > systemd has a build-dependency on util-linux for libmount, and util-linux has an
> > optional build dependency on systemd.
> > 
> > The features in util-linux that enabling systemd gives you are:
> > * lslogins can show recent journal entries from the user
> > * uuidd can use socket activation and has a service file
> > * fstrim has a service file
> > * logger can write journal entries
> > 
> > These are not worth the overhead of maintaining two util-linux recipes to
> > bootstrap the cycle, so disable systemd support in util-linux.
> 
> I feel we are going out of way here since now on systemd based systemd you have to undo this change
> partly via re-introducing service files in some fashion
> how about just building and packaging uuidd and fstrim separately ?
> 
> atleast it should be reported to util-linux maintainers.

I'm going to merge this patch and I want to clearly explain why.

With systemd it does seem to pay to be one something approximating the
latest version. I can't do that without doing something about
util-linux.

In history we have no good example of successfully splitting one piece
of source over multiple recipes, apart from perhaps gcc which we'd all
agree is horrible in a variety of ways. Any time we have attempted this,
we've tended to revert or have calls to revert (e.g. avahi).

We're at M3 cutoff and we need to make some decision. If I choose not to
take this, nothing will make 1.8. If I take this, there is the
possibility we can fix up systemd util-linux in some way if it proves to
be that critical.

So whilst I don't think this is perfect and I agree it needs discussion
with the util-linux/systemd folks, I think its perhaps the least worst
option available to me and there are ways we can likely improve things
if/as needed.

Cheers,

Richard





More information about the Openembedded-core mailing list