bug 58002

Matt Zimmerman mdz at ubuntu.com
Sat Sep 9 00:14:16 BST 2006


On Tue, Aug 29, 2006 at 04:45:44PM -0500, Rocco Stanzione wrote:
> I have questions for this specific bug and for bugs in general.  For this
> bug, is there an appropriate solution at all?

We should hope so.  Unfortunately, the issue is not straightforward.  sudo's
default behaviour does what the user expects in some cases, but not in
others.

For an example of the former, compare "sudo gedit /etc/motd" to
"sudo -H gedit /etc/motd".

You've described an example of the latter in your bug report.

> My recommendation (hadn't thought of it by the time I decided to wash my
> hands of the launchpad bug) is to put an empty /etc/skel/.viminfo into the
> vim package, which would fix this and have no other consequences that I
> can think of.  Modifying sudoers to always set home was also suggested,
> but I think that would have some unintended consequences.  I figure the
> answer to that will determine which package, if any, this bug should be
> filed against.

This is a workaround, not a fix, and one which I'm not sure is worth the
tradeoff.  The underlying issue needs to be addressed with a globally
consistent policy.  I've adjusted the description of the bug accordingly,
and encourage the QA team to mark similar bugs as duplicates of that one,
since it needs a general solution.

My gut feeling is that we probably want to adjust some of the default
environment variable settings and sudo's list of preserved variables, to
preserve the convenience provided by the current setup, and then switch to
always_set_home. I think this needs serious thought and discussion before we
agree on a solution, however.

> In general, what can we do to prevent this kind of thing?  I'm hard
> pressed to go what I see as a troublesome bug because somebody says vim's
> behaving correctly, therefore it's not a bug.  Dennis was hard-pressed to
> let go what he believed was an invalid bug report.  When in doubt, do
> what?  When there's apparently a problem where the bug isn't in the
> package that feels the symptoms, where to file the bug until the solution
> is decided on?

When there is a conflict, seeking a second opinion (as you have) is a
reasonable next step.

-- 
 - mdz



More information about the ubuntu-devel mailing list