Hello Raphaël Halimi, Congrats on completely derailing a thread that for once was about proper mainenance and solving a bigger problem into becoming about your pet peeve. Please feel free to stop CCing me if you don't actually want my feedback.
On Tue, Dec 13, 2016 at 11:01:19PM +0100, Raphaël Halimi wrote: > Wontfix ? Really ? Are you that much intent on killing sysvinit ? Unless by "killing sysvinit" you mean "use it as intended", then no. > > Last time I checked, the Policy still required alternative init systems > to be supported by package maintainers. I wonder which policy you're reading then. Fwiw, I recently posted patches to policy to make it sysvinit compatible, but maybe we should go the other way around and cite the current very outdated policy as a reason for sysvinit removal instead? > Since it's so easy to override > these settings with systemd (I'm not ironical here, I really don't know > how it's done), what harm would this patch do if it was applied to > satisfy sysvinit users ? If you think it's about making it easy to do it in multiple separate ways, then you don't understand the problem. You want exactly *one* way to do it that's supported by all, so we can continue keeping that one way working and avoid incompatible upgrades. You know Debian cares alot about integration and easy upgrades, right? > > They would have at last the possibility of modifying rpcnfsdopts through > /etc/default/nfs-kernel-server, and thus reliably disable nfsv4, and > systemd users could still do the same through whatever facility systemd > provides and that I'm not aware of. You already have this option. These files are conffiles. Please read up on what that means (in policy for example). Maybe also think a bit about why making incompatible changes to conffiles and shipping new versions of them in a package is something you want to avoid as a maintainer, and why a user don't want a maintainer to do that either. Regards, Andreas Henriksson
