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

[Richard Purdie]

On Tue, 2015-02-24 at 16:00 -0800, Khem Raj wrote:
> On Tue, Feb 24, 2015 at 3:32 PM, Richard Purdie <rpurdie at rpsys.net> wrote:
> >
> > 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).
> 
> I asked for specific problems/issues observed with split builds. I got
> no concrete examples, yes it has to be done carefully but then I dont
> think its something that can not be fixed destabilize the release so
> much. We are building it twice identically and just changing the
> packaging. In any case, sometimes we should try to tackle the issues
> out of milestone pressures too.

You're not building it twice identically, if you were doing that we
wouldn't have this problem. You're trying to split it into two separate
chunks and ensuing they are independent, yet they do inter-depend
correctly when needed too.

If this is just a packaging problem, we should just ship the extra
systemd unit parts as part of a separate recipe and then have the main
util-linux recipe RDEPEND on it.

Specific examples:

You need to ensure that the PACKAGES generated by both sides of the
split have consistent naming (maybe overriding and doing what debian
packaging would have done should the split not been there). The PACKAGES
need to be careful about the contents of default PN for example. There
have been issues cleanly separating things into two -dev packages and
exposing two similar but slightly differently named -dev packages for
the same piece of software.

You have to ensure that the appropriate recipes each register as the
correct shlibs providers and that things DEPENDing on the recipe now
depend on the correct recipe.

We end up with two separate do_install tasks which are fragile and that
changes during version upgrades get handled correctly with changes being
made to both functions equally and carefully. avahi has tended to break
more readily than other recipes duing upgrades.

The PROVIDER namespaces must not overlap and MLPREFIX needs to be
correctly injected into the correct places, particularly given the more
hardcoded package names.

Now, I agree we can probably hand craft a recipe which works and doesn't
have any problem above. Is it maintainable? Will issues come up in the
future? Am I going to get 101 questions and complaints about it?

I don't believe it is as easy as you think to take this forward long
term, much a I wish it were otherwise...

Cheers,

Richard