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 -- _______________________________________________ meta-virtualization mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-virtualization
