[meta-virtualization] [PATCH] containerd: remove redundant systemd detection

Bruce Ashfield bruce.ashfield at gmail.com
Wed Mar 14 06:07:44 PDT 2018


On Wed, Mar 14, 2018 at 8:46 AM, Bach, Pascal <pascal.bach at siemens.com> wrote:
>> On Wed, Mar 14, 2018 at 4:39 AM, Pascal Bach <pascal.bach at siemens.com>
>> wrote:
>> > The variables only take effect if systemd is enabled so the check can be
>> removed.
>> >
>>
>> Same comment.
>>
>> This layer, and many others, have always had this check since that's how the
>> systemd classes worked before.
>>
>> Can you log the oe-core commit that changes the behaviour in the long log of
>> the two cleanup patches ?
>
>  I cannot point you to a specific commit in oe-core. But I also don't see anything like this anywhere else.
> All recipes in oe-core I had a look at just set these variables, no checks.
>
> So you make any observations that makes the check necessary in this layer but not in oe-core?

Throughout the various systemd integrations, we've had services that
didn't start/install when they should, we've had services that would start
when the shouldn't, and all sorts of other combinations.

Plus historically we supported both systemd and sysvinit, so both the
packaging and install rules needed to be conditional on the init system.

In those same recipes, the .service files aren't being installed if systemd
isn't enabled.

Although I haven't tested it lately, IIRC, that lack of .service file + the
packaging being enabled triggers a warning or error.

I'm actually fine in walking away from sysvinit support, but I know there are
still some users of it, so I should first document it as depreciated, throw a
warning and then remove it completely in the next release (i.e. not just these
cleanups, but remove all the systemd init system checks).

Bruce

>
> Pascal
>
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"


More information about the meta-virtualization mailing list