Hi, On Wed, Dec 04, 2019 at 04:43:39PM +0100, Ansgar wrote:
> For one of the problems (apt making unexpected decisions) that is > pretty close to what is the case. We do find such issues again and > again, including too late, i.e. only after a stable release, also for > other packages that aren't related to init systems. The experience is the same on the other side of the pond. I think the problem is the transition process that forces us to make dependencies weaker than they should be to have a satisfactory result. 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. > 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? IIRC installing systemd-sysv should deinstall systemd-shim, so the obvious broken configuration is locked out. > 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. Guaranteeing that the system will only ever consume one of the two files would allow us to drop a lot of ugly hacks in individual packages, but at the price of a big ugly hack in the compatibility generators (which we still need to provide for users who want to run non-Debian software). Simon
