On Wed, Dec 04, 2019 at 06:04:19PM +0100, Simon Richter wrote: > One of the options I had in my original proposal was that we could drop the > requirement for transitions through apt, and instead provide transition > scripts that use dpkg's --force options to go through an invalid state > instead of requiring all intermediate states to be valid. I think apt already does that sometimes? > > In this discussion I provided a popcon graph which shows that systemd- > > shim has significantly more installations than sysvinit-core; if you > > prefer inline numbers: for stretch there are 3335 systemd-shim > > installations and 775 sysvinit-core installations. So it looks like > > something isn't quite as wanted. (And likely not all 775 sysvinit-core > > installations even have systemd-shim, so the unwanted case is even a > > bit larger; I'm too lazy to check that right now.) But even getting > > some people to acknowledge this seems very hard. > > Could these be upstart based? I doubt that, looking at the popcon data for upstart itself. Though I don't know how to get the data for stretch specifically. > > I also tried some related things, including some proposals to improve > > systemd support via Policy proposals that don't even degrade support > > for sysvinit such as recommending to always include native systemd > > units where approporiate. That now went back to someone questioning > > whether one should recommend to (almost) *never* include native systemd > > units instead... > > I'd be in favour of always including units along with init scripts, ideally > as a strong requirement so we can disable the init script compatibility > layer in systemd, and the same for cron files and timer units. The relevant policy bug is #941198. -- WBR, wRAR
Attachment:
signature.asc
Description: PGP signature