I'm not sure how you want to implement this but my suggestion is to RDEPEND on {x11,gtk}-ssh-askpass and probably create a env.d file to avoid this: %% sudo -A bash sudo: no askpass program specified, try setting SUDO_ASKPASS Thoughts?
I don't think it'd be the best idea sincerely to add a dependency over x11-ssh-askpass on sudo. What about enabling the setting on a sudo USE flag for the two askpass programs intead?
yea, USE=X is probably the best solution.
I think you guys are still approaching this from two sides. I believe Diego is saying to add USE=sudo to x11-ssh-askpass while Jeremy is proposing adding USE=X to sudo to depend on x11-ssh-askpass. (it's worth noting that gtk2-ssh-askpass is no longer in the tree) Both have their merits, but assuming -A could be made default if SUDO_ASKPASS is set, I would think USE=X in sudo would make more sense (as I think that default I described would make sense).
Created attachment 175900 [details] suggested sudo-1.7.0.ebuild patch Ok, well. If ssh-askpass-fullscreen has USE=sudo then install the env.d SSH_ASKPASS file..easily done with USE deps. I just have to mod the askpass ebuild..trivial. Let me know.
(In reply to comment #4) > Created an attachment (id=175900) [edit] > suggested sudo-1.7.0.ebuild patch > > Ok, well. > > If ssh-askpass-fullscreen has USE=sudo then install the env.d SSH_ASKPASS > file..easily done with USE deps. I just have to mod the askpass > ebuild..trivial. Let me know. > So, know that sudo-1.7.0 is stable...what are we going to do? The -A flag on sudo is not convienient by default for the end user.
(I guess there is a new sudo maintainer, Diego is not in metadata anymore) I don't know why I didn't think of this before. But it is even more trivial than originally suggested. 1) Add USE=X to sudo ebuild. 2) X? ( net-misc/ssh-askpass-fullscreen ) 3) doenvd "${FILESDIR}/100sudo_askpass" || die %% cat "${FILESDIR}/100sudo_askpass" SUDO_ASKPASS=${SSH_ASKPASS} Can I implement it with a revbump on the latest ~arch sudo package?
It has moved to base-system but I'm still looking after it unless you want to take it _including all the stupid user bitching_. I still think that the env.d file should not be installed by sudo but rather by the askpass program. And what happens if you're not running under X, if -A is made default? Will it fallback to the standard request or would it fail?
(In reply to comment #7) > It has moved to base-system but I'm still looking after it unless you want to > take it _including all the stupid user bitching_. Not me. > > I still think that the env.d file should not be installed by sudo but rather by > the askpass program. The sudo package has the -A flag, not the askpass program, seems wrong to me to have another package do something for an option for the real package. yes? > > And what happens if you're not running under X, if -A is made default? Will it > fallback to the standard request or would it fail? Who said -A is the default? Basically, if you are willingly using -A, then you are willingly in X. If a program is using sudo -A then it should be an X/gtk/etc program so you are in an X env. > Basically, I'm trying to make Gentoo ship a working sudo program, instead of something that is broken OOTB. I hope you agree with this idea. I don't understand why you want the askpass program to set the env.d file for sudo. If askpass does do it (which is fine, I can make it so) then sudo still needs to depend on askpass or else we are in the same situation that sudo -A *might* not work (automagically works for some users and some not)
(In reply to comment #7) > And what happens if you're not running under X, if -A is made default? Will it > fallback to the standard request or would it fail? Fails because ssh-askpass cannot open. Again, this bug is not about making -A the default, it is about making all options of sudo working OOTB. :)
Since: a) sudo does not *need* -A and is _perfectly working as it is_ (if you want to argue that it's “broken out of the box” you're going to piss me off — your only working); b) sudo should not know which program provides an askpass feature (otherwise it would know without the environment flag); c) there might be multiple askpass programs out there (there used to be multiple, at least!); d) the dependency sudo→askpass is moot; it'd be forcing one selection out of multiple alternatives, it should instead suggest the user to install it.
you're not going to get a different response from base-system. Diego has been maintaining the package and whatever his opinion is goes.
(In reply to comment #10) > Since: > > a) sudo does not *need* -A and is _perfectly working as it is_ (if you want to > argue that it's “broken out of the box” you're going to piss me off — > your only working); Not my intent, you know that. > b) sudo should not know which program provides an askpass feature (otherwise it > would know without the environment flag); Different distros do different things. Ubuntu call ssh-askpass-fullscreen just ssh-askpass. > c) there might be multiple askpass programs out there (there used to be > multiple, at least!); Indeed, but they are not mutually exclusive. > d) the dependency sudo→askpass is moot; it'd be forcing one selection out of > multiple alternatives, it should instead suggest the user to install it. > In the interest of agreeing to disagree, I made ssh-askpass-fullscren now set SUDO_ASKPASS variable (comment #7 requested by you). Current state is that sudo -A works for a random set of gentoo users without user intervention. Feel free to resolve this bug as you see fit, elog, etc, your call.
Fixed. Note that you got a problem with the x11-ssh-askpass package not being considered at all, but feel free to do whatever.
