Alan Jenkins: > On 09/06/17 18:55, Niels Thykier wrote: >> [...] > > :-(. I guess my hope was, this bug report showed some sort of > precedent, that policy did not prevent the idea. Otherwise, this bug > would have been shut down earlier on. >
Sorry, it doesn't. :) > I.e. the code running `update-rc.d FOO disable` at removal, would surely > overwrite the customization done by the admin, but that didn't stop that > code being pushed to unstable. (And it's not the reason it was reverted). > I assumed it didn't given the request. Turns out I was wrong to assume it, which makes me glad that the other part broke so quickly. I am not sure anyone would have noticed the overwrite part until much later. > [...] > > It suggests, this proposal would also need to save the enabled state(s) > at package removal and be able to restore them later... Correct, and all of that logic should basically be in update-rc.d (so the details of how that state is stored is not embedded into thousands of maintscripts) > but that's more than I'd be willing to implement. > That is entirely fair. :) At the moment, I don't have time to do this either. > However I can imagine saving a "mask" under /var/lib/update-rc.d/, which > has a similar disabling effect to a systemd mask. Implementing this in > /etc/init.d/rc. And patching the systemd-sysv-generator to match it. > If you are up for it, I can CC the maintainers of the relevant packages and we can hear if they think it would be a viable solution. :) > For native systemd services... I would then be able to simply remove all > the `mask` code in dh_systemd_enable, to solve my issue (described in > #864504) > > Alan > > [...] :) Thanks, ~Niels
