On Fri, Oct 2, 2009 at 2:30 AM, Joshua Murphy <poiso...@gmail.com> wrote: > 2009/10/2 Arthur D. <spinal...@mail.ru>: >>>> You appear to be demonstrating that you don't fully understand the >>>> problem: >>>> >>>> 828 ~ $ grep nano /usr/portage/app-admin/sudo/sudo-1.7.2_p1.ebuild >>>> # XXX: /bin/vi may not be available, make nano visudo's default. >>>> --with-editor=/bin/nano \ >>> >>> How so? That config option for sudo sets the DEFAULT editor, what to use >>> if nothing is defined in the config file or environment variable. That's >>> what both my text and the portion of the ebuild that you have quoted >>> state. It in no way forces the use of nano in order to use visudo. If >>> that were the case, DEPENDS would specify nano instead of accepting >>> virtual/editor. >> >> Agree. There's no need in making vim as depends. But in other hand in >> vanilla sudo >> package there's VI hardcoded by default. And MOST if not ALL users who have >> VIM >> installed on their shiny Gentoo systems expect that VIsudo will behave as it >> did >> for long tim ago. There are historical (or some other) reasons for making VI >> default >> editor for this utility. It's like they don't respect not only endusers >> favours but >> the developers' too, no? >> >> WHY NOT CHECK if vim binary is in place and ONLY THEN (when it's obviously >> absent) >> hardcode the Gentoo Best Award of Choice Editor? >> >> I repeat once more. >> Every user who has VIM installed on theirs systems is forced to do extra >> configuration, to make sudo work as expected, just because someone prefer >> other editor and thinks that vanilla choice is bad. Isn't that just stupid? >> >> -- >> Best regards, Spinal > > And everyone who has emacs has to do extra work too, in order to get > sudo to respect their chosen editor. Changing the default fallback for > visudo when the environment variable isn't defined will add in further > dependencies and/or put a dependency on a package that can't be > reasonably assumed to be on the system in the near future. You're not > being forced to do more work because you use vim, you're doing more > work because you remove the sane default editor from the system. As > does everyone removing nano and using pico.... and... how many others? > Go to LFS, build it all, build emacs, set EDITOR to emacs, and run > sudo visudo. Please. I have a rather good guess that you'll be, > amazingly, using the default that was set at build time for the sane > default editor, in LFS's case vim (whether called by that or the vi > symlink to it), that the distro creators chose. Or if you vary from > the instructions, choosing some other editor at sudo's build time, > you'll be running that. The ebuild does the logical thing in choosing > an editor that a) is in place by default and b) is less likely to be > on the system or off the system by the admin's whim. Most leave the > default in place. I suppose, really, the only more guaranteed editor > would be "busybox vi" ... because VERY few go about breaking the > default tools built into busybox... but what would that leave the many > who use nano by default, as... it IS the distro default, to do? > Compared to nano, vi (let alone a bare minimal vi like is in busybox) > is a pain to use for a person who's never seen it before. > > Also, randomly, I could be wrong here, not being a sudo user myself > outside of my ubuntu laptop... but if you look into sudo ... it drops > the environment, aside from those chosen specifically to be preserved > by root, through its configuration, as a security measure. It's not an > ebuild problem, it's not a 'defaults' problem. From what you seem to > see as 'proper' behavior for sudo, it's an upstream security decision > problem. > > -- > Poison [BLX] > Joshua M. Murphy > Yet another vim user. >
Oh! and 2 more things. 1) In answer to the subject-posed question (in case it wasn't clear in my post just above)... yes. 2) And... your problem shouldn't be with the default set in the ebuild, but rather, the lack of a sed line in the ebuild to adjust sudo's initial configuration to retain, at the least, the EDITOR environment variable. That would, were the answer to your subject-posed question anything other than an unequivocal yes, be the most universal resolution to the problem that you seem to think exists in the setup as it is now. No ebuild should depend on an environment variable like EDITOR at build time if they can, even remotely, avoid it. That would require a rebuild every time the environment variable changed and... that would be rather jarring to say the least. -- Poison [BLX] Joshua M. Murphy
