Current eselect file has: SYMLINK_TARGETS=( pinentry-qt pinentry-gtk-2 pinentry-qt4 pinentry-curses pinentry-gnome3 ) As the first is preferred by bin-symlink.bash, people having both USE flags (gtk and gnome-keyring... that is the default for all Gnome users) will always get the old gtk2 one selected over gnome3 one by default. This could be avoided simply moving pinentry-gnome3 over pinentry-gtk2 and this won't affect non gnome users as those won't have "gnome-keyring" USE enabled and, then, pinentry-gnome3 won't be installed Thanks
(In reply to Pacho Ramos from comment #0) > Current eselect file has: > SYMLINK_TARGETS=( pinentry-qt pinentry-gtk-2 pinentry-qt4 pinentry-curses > pinentry-gnome3 ) > > As the first is preferred by bin-symlink.bash, people having both USE flags > (gtk and gnome-keyring... that is the default for all Gnome users) will > always get the old gtk2 one selected over gnome3 one by default. Personally I prefer it that way, i.e. that the optional gnome3 functionality is specifically activated. This should be easy enough to write up in a wiki or whatnot, or elog during installation of related packages.
(In reply to Kristian Fiskerstrand from comment #1) > (In reply to Pacho Ramos from comment #0) > > Current eselect file has: > > SYMLINK_TARGETS=( pinentry-qt pinentry-gtk-2 pinentry-qt4 pinentry-curses > > pinentry-gnome3 ) > > > > As the first is preferred by bin-symlink.bash, people having both USE flags > > (gtk and gnome-keyring... that is the default for all Gnome users) will > > always get the old gtk2 one selected over gnome3 one by default. > > Personally I prefer it that way, i.e. that the optional gnome3 functionality > is specifically activated. This should be easy enough to write up in a wiki > or whatnot, or elog during installation of related packages. I was about to reply the same :)
I don't see much sense on defaulting to old gtk2 pinentry for people enabling "gnome-keyring" USE flag :/. With current setup all people with that setup will need to change the provider
(In reply to Pacho Ramos from comment #3) > I don't see much sense on defaulting to old gtk2 pinentry for people > enabling "gnome-keyring" USE flag :/. With current setup all people with > that setup will need to change the provider gtk2 is not old it is an option detached from gnome, this option is what gnupg upstream supports. the issue is gnome specific. as far as I can see eselect-xxx does not have USE flags, it selects based on priority provided by author, in case of pinentry the upstream options should be first.
I am referring to the USE flags from app-crypt/pinentry... that uses eselect-pinentry and, then the problem appears as it forces all people wanting gnome integration to change that setting manually. If pinentry is emerged without "gnome-keyring" USE flag, eselect-pinentry will simply go to the next option and then it will still use the gtk2 one (well... if you want to make it even more "gnome specific", maybe the pinentry "gnome-keyring" USE flag could be renamed to "gnome" to clarify it will add gnome integration support)
the only thing we can do is to add virtual/pinentry so that gnupg will depend on this instead of app-crypt/pinentry, of course default will be app-crypt/pinentry. if you think all gnome users will want the gnome pinentry you can pull it directly within gnome packages. gnupg and pinentry should not be gnome aware, the eselect-pinentry should prefer upstream if exists.
Maybe I understand now what you want... sorry for the delay. You want app-crypt/pinentry to skip build of gtk2 if gnome-keyring USE is enabled? This I can understand.
Well... I have no problems on having both (gtk2 and gnome) pinentry providers present. The situation is: - Most gnome users will have "gnome gnome-keyring gtk" globally enabled in USE flags => This will lead to both pinentries being built but gtk2 still being preferred even for this "gnome setup" Moving the order in eselect module will solve this while not affecting to people running with "-gnome-keyring" and, then: - gnome users will still have gtk2 pinentry built (if they want to use it for testing or some other strange reason) but gnome3 one preferred - Non gnome users will see no change as they won't have the new gnome3 pinentry built and, then, they will still follow to upstream preference on gtk2 one
In other words, what is proposed is that have a relevant default for people having gnome profile selected while still respecting upstream default for others.
(In reply to Gilles Dartiguelongue from comment #9) > In other words, what is proposed is that have a relevant default for people > having gnome profile selected while still respecting upstream default for > others. If we end up doing this I actually agree the correct place to do it is in eselect-pinentry rather than completely disabling the gtk2 version in pinentry, that changes the default but leaves the optionality. As this seems to be a strong request from gnome, and it is controlled through a gnome-keyring USE flag, i.e clearly specific to gnome and this pinentry variant is included in upstream, so its not such a large deviation, upon some more thinking I'm actually OK with such a change.
ok
(In reply to Alon Bar-Lev from comment #11) > ok *eselect-pinentry-0.6 (01 Jul 2015) 01 Jul 2015; Kristian Fiskerstrand <k_f@gentoo.org> +eselect-pinentry-0.6.ebuild, +files/pinentry.eselect-0.6: If pinentry-gnome3 exist, prefer this over the qt and gtk versions. The version will only exist if gnome-keyring is specified for pinentry build.
Thanks guys.
Thanks a lot :)
