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

[Khem Raj]

> On Feb 24, 2015, at 4:28 PM, Richard Purdie <rpurdie at rpsys.net> wrote:
> 
> 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.

yes we are look at

http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/misc&id=c53322e9e587ef9a88c050f21aa98604deeeeb1f

just install and packaging are differing.


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

util-linux provides service files and its better to keep using those for maintenance reasons if we strip them out into auxiliary
packages its same amount of hassle during upgrade as splitting is.

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

there are separate sub-targets which avoids this issue. 

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

isn’t that automatic ? it informed me of the changing providers for shared libs, util-linux packaging is quite granular
and the move to libs is at output PACKAGES boundary, just the recipe provider is changing.

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

We could use common include. I did not bother in version 1 but it certainly is possible.

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

While I agree its a bit of more work but its future safe. and the patch I mentioned above does not address
all concerns but it can be made to do so. The steps you describe are all valid but we have a better
case with util-linux than other examples you mentioned.

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