Hi Andreas Henriksson, Le 14/12/2016 à 08:21, Andreas Henriksson a écrit : > 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. That wasn't my intention at all. I was sincerely happy to see some growing activity in the maintenance of NFS packages and I seized this opportunity to point out a trivial patch rotting for one year in the BTS that could fix two separate bugs, and allow to effectively close them. In other words, I was *trying to help*. On the contrary, it's you who, as usual, treated people who don't use systemd with utter contempt, by suggesting to close both bugs as wontfix, and by doing so, transformed part of this thread in a potential mini-flamewar. Or maybe it is a personal vendetta against me about our previous quarrel in #773915 ? Frankly, I don't care, but I'd like to say that I just contribute to Debian in the hope that it (and its derivatives) will work out-of-the-box for most people, but it seems to me that you want Debian to work exclusively for systemd and GNOME users, purposefully brushing aside other people's efforts in the opposite direction. Now for the technical side of the problem: >> 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. Exactly, and AFAIK /etc/default snippets *are* this universal way. How else would you do it for it to work with both systemd and sysvinit ? Besides, rpcbind already uses this mechanism through /lib/systemd/system/rpcbind.service (line "EnvironmentFile=-/etc/default/rpcbind"). Why would it be such a bad idea for nfs-utils ? > You know Debian cares alot about integration and easy upgrades, right? Please stop being condescending. I use Debian since 1998 so yes, I know that, but "caring about easy upgrades" does not mean "leave bugs unfixed just to avoid a conffile prompt during upgrades". >> 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). I know what a conffile means in the Debian jargon, and I'm perfectly fine with modifying them, except for init scripts. When the maintainer changes an init script, reconciling the differences with local modifications is both cumbersome and error-prone, and I do my best to avoid that. > 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. Please explain exactly in what way would my patch introduce *incompatible* changes. It's *trivial*, it only adds a single option, and a comment to hint that NFSv4 must be disabled in rpc.nfsd in addition of rpc.mountd. Why do you deem this change as "incompatible" ? Just because of a single conffile prompt that would affect a minority of users ? Regards, -- Raphaël Halimi
Attachment:
signature.asc
Description: OpenPGP digital signature