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

[Bach, Pascal]

Hi Bruce

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

I don't think there is a need to drop sysvinit. They can coexist without problem.
We used many recipes that have both sysvinit and systemd service and never had any issues at least since pyro.

Pascal