On Fri, Aug 26, 2011 at 09:08:48AM +0000, Thorsten Glaser wrote: > Bdale Garbee dixit: > >Nothing is "forced on the user", the conffile handling is doing exactly > >what is expected. If the admin chooses to not accept the update, the > >worst that happens is they have to fully qualify command paths until > >they've patched up sudoers. > > Yes, that’s inconvenient but manageable (except in the face of > automated upgrades). Also, the normal conffile handling only > has a yes-or-no approach (and a “let me spawn a shell” one), > none where you can interactively merge (like with diff3 when > CVS has a merge conflict) the change…
Yes, but implementing a method like this is way beyond the amount of work that a normal package is expected to invest. I'd hate to open this can of worms in sudo, a package which is installed on nearly every Debian system. I'd also like to refrain from adding a ucf dependency here. > >> Also, visudo now asks > >> | press return to edit /etc/sudoers.d/README: > >> which, while cosmetic, will lead to much frustration and some > >> confusion under the sysadmins. > > > >I don't see that. What command causes you to get that message? > > sudo visudo > ⇒ opens an editor on the tmp for /etc/sudoers > ^Kx (exits the editor) > ⇒ displays the message > <return> > ⇒ opens an editor on the tmp for /etc/sudoers.d/README This doesn't happen on current unstable with vi as the EDITOR. > This is because /etc/sudoers contains > | #includedir /etc/sudoers.d > and /etc/sudoers.d/README is a file in that directory… Did visudo at one time actually invoke the Editor with /etc/sudoers AND /etc/sudoers.d/* ? It doesn't seem to do this any more. Can we please close this bug report? I don't think that keeping it open makes any sense. Or would you prefer it as a wontfix bug with the subject "uses default dpkg conffile handling for /etc/sudoers"? Or am I misunderstanding things? Greetings Marc
