There are some 3rd-party out-of-tree implementations for pinentry like app-crypt/pinentry-bemenu in guru. It would be nice to have those selectable by app-eselect/eselect-pinentry. It's obviously not expected to list all those implementation gentoo doesn't have control over, but it would be nice to provide some control to the end-user. The implementation may be as simple as this: --- a/app-eselect/eselect-pinentry/files/pinentry.eselect-0.7.2 +++ b/app-eselect/eselect-pinentry/files/pinentry.eselect-0.7.2 @@ -6,7 +6,7 @@ MAINTAINER="maintainer-needed@gentoo.org" VERSION="0.7.2" SYMLINK_PATH=/usr/bin/pinentry -SYMLINK_TARGETS=( pinentry-efl pinentry-gnome3 pinentry-qt5 pinentry-curses pinentry-tty ) +SYMLINK_TARGETS=( $(cd "${EROOT}/usr/bin/" && ls -d pinentry-* 2>/dev/null) ) SYMLINK_DESCRIPTION='pinentry binary' inherit bin-symlink Reproducible: Always
Some revdeps have USE-deps on app-crypt/pinentry, how is that going to be resolved?
(In reply to Andreas Sturmlechner from comment #1) > Some revdeps have USE-deps on app-crypt/pinentry, how is that going to be > resolved? It won't be. And it's not really needed too. Without any gui flags app-crypt/pinentry will just provide pinentry-tty as a fallback. Against which I believe even the most thorough purists won't object. But that's beyond the scope of the bug. It's just about being able to select an another implementation via `eselect pinentry` without extra hassle...
Why would you need this? "eselect pinentry set pinentry-bemenu" (e.g.) should work out of the box. (In reply to Fat-Zer from comment #0) > -SYMLINK_TARGETS=( pinentry-efl pinentry-gnome3 pinentry-qt5 pinentry-curses pinentry-tty ) > +SYMLINK_TARGETS=( $(cd "${EROOT}/usr/bin/" && ls -d pinentry-* 2>/dev/null) ) This is not allowed: .. Warning:: In ebuilds, global scope code can cause problems. In eselect modules, global scope code is **absolutely forbidden**. Your module *will* be sourced for tasks other than running your actions. For example, if ``eselect modules list`` is executed, your module will be sourced to obtain the description. Any code being run here would be a very bad thing. https://wiki.gentoo.org/wiki/Project:Eselect/Developer_guide#A_simple_module
Created attachment 881794 [details, diff] Propoused patch for pinentry.eselect
(In reply to Ulrich Müller from comment #3) > Why would you need this? "eselect pinentry set pinentry-bemenu" (e.g.) > should work out of the box. Raw "ln -sf pinentry-bemenu /usr/bin/pinentry" works too, there is for sure no strict necessity in that, but eselect is about some extra level of convenience, IMHO it'd be just a nice thing to have. Though, I won't insist on it if it will be PIA to implement, so feel free to close the bug in such case. > This is not allowed: > > .. Warning:: In ebuilds, global scope code can cause problems. > In eselect modules, global scope code is **absolutely forbidden**. > Your module *will* be sourced for tasks other than running your > actions. For example, if ``eselect modules list`` is executed, your > module will be sourced to obtain the description. Any code being run > here would be a very bad thing. > > https://wiki.gentoo.org/wiki/Project:Eselect/Developer_guide#A_simple_module make sense... I've added another proposed patch (small enough, though a bit hacky).
I'd say that find_targets() and TARGETS are internal and undocumented functions and variables of bin-symlink.bash, so the module shouldn't rely on them. If you really want something like this, one way to go would be to add some wildcard mechanism to the library. CCing maintainer of app-eselect/eselect-lib-bin-symlink. Alternatively, I see no harm in adding a couple of out-of-tree implementations to SYMLINK_TARGETS. In fact, this would be a less intrusive change.
(In reply to Ulrich Müller from comment #6) > I'd say that find_targets() and TARGETS are internal and undocumented > functions and variables of bin-symlink.bash, so the module shouldn't rely on > them. > > If you really want something like this, one way to go would be to add some > wildcard mechanism to the library. CCing maintainer of > app-eselect/eselect-lib-bin-symlink. `app-eselect/eselect-lib-bin-symlink` is a part of the eselect itself right now... So it'd be a slightly harder task for pushing of changes into... But if we are onto this, I'd be all-in for approach of "install some file to add an alternative" like installing a `/usr/share/eselect/alternatives/pinentry/bemenu`: `pinentry-bemenu` which could be installed by `app-crypt/pinentry-bemenu` in the example. But having pinentry as the only example that would benefit from the change it would be hard to push for it... I haven't thought before of "adding globbing to the `eselect/lib/bin-symlink`" approach, but it might be actually a nice compromise idea too... On the other hand it might be possible to push towards documenting of utilising find_targets()/TARGETS in such way. > Alternatively, I see no harm in adding a couple of out-of-tree > implementations to SYMLINK_TARGETS. In fact, this would be a less intrusive > change. Cards on the table: I was pushing for this one while having in mind trinity (KDE3 fork) repository[1]. As for now it's not even a part of official `eselect repository` list, but it has an `app-crpt/pinentry-tqt` ebuild which is a continuation of a qt3 source code in the pinentry source base. As for now the overlay has its own app-eselect/eselect-pinentry version but it's already outdated and unmaintainable in the long-term, so I was hoping to drop it and introduce its support by the upstream version in some way. I know that gentoo mainstream is not very inclined toward supporting of outside projects, so I believed the better approach would be to represent the issue in a more universal way, taking an example from an already a semi-official overlay. [1]: https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging-gentoo
