Created attachment 421508 [details] emerge --info localhost / # emerge --ask gnome-base/gnome-keyring * IMPORTANT: 11 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] gnome-base/gnome-keyring-3.18.3::gentoo USE="caps filecaps pam ssh-agent -debug (-selinux) {-test}" 1,177 KiB [ebuild N ] app-crypt/pinentry-0.9.7::gentoo USE="gnome-keyring gtk ncurses qt4 -caps -emacs -qt5 -static" 423 KiB [ebuild N ] app-crypt/gcr-3.18.0:0/1::gentoo USE="gtk introspection vala -debug {-test}" 1,281 KiB [ebuild N ] app-crypt/gnupg-2.1.10-r1::gentoo USE="bzip2 gnutls ldap nls readline usb -doc (-selinux) -smartcard -static -tofu -tools" 5,053 KiB Total: 4 packages (4 new), Size of downloads: 7,933 KiB * Error: circular dependencies: (app-crypt/pinentry-0.9.7:0/0::gentoo, ebuild scheduled for merge) depends on (app-crypt/gcr-3.18.0:0/1::gentoo, ebuild scheduled for merge) (runtime) (app-crypt/gnupg-2.1.10-r1:0/0::gentoo, ebuild scheduled for merge) (buildtime) (app-crypt/pinentry-0.9.7:0/0::gentoo, ebuild scheduled for merge) (buildtime) * Note that circular dependencies can often be avoided by temporarily * disabling USE flags that trigger optional dependencies. localhost / # Similar problem appears when trying to update the world set without global "-gnome-keyring" USE flag.
This was introduced when fixing bug 560322, but it looks like, if needed and compile time, we won't be able to move the dep to PDEPEND :S
COMMON_DEPEND_BINS="app-crypt/pinentry !app-crypt/dirmngr" # Existence of executables is checked during configuration. DEPEND="${COMMON_DEPEND_LIBS} ${COMMON_DEPEND_BINS} Neither in gnupg ebuilds :S
This is easy enough to work around by emerging pinentry without gnome-keyring USE flag as a first iteration to bootstrap with gpg (which will likely be in @system in the future due to portage OpenPGP verification to begin with). But let me try to think of a solution to it anyhow..
moving dep into PDEPEND works perfectly for pinentry, not sure why it considered not workin. And this breaks the circ.
test case: move gnome-keyring conditional dep of gcr in pinentry into PDEPEND. Remove all of gcr, gnome-keyring, pinentry and gnupg. Re-emerge all of them with USE="gnome-keyring". circ dep does not occur, also pinentry installed just fine without having gcr yet merged, so #560322 need more investigation, i cannot reproduce that failure without gcr installed.
it's ~arch >=pinentry-0.9.6
(In reply to Pacho Ramos from comment #1) > This was introduced when fixing bug 560322, but it looks like, if needed and > compile time, we won't be able to move the dep to PDEPEND :S Does gcr really require gnupg at build time? in what way does it invoke gnupg?
(In reply to Oleg from comment #4) > moving dep into PDEPEND works perfectly for pinentry, not sure why it > considered not workin. And this breaks the circ. iirc there was a conditional in there for that statement. using a PDEPEND for pinentry might be a viable option in this case, but want to check out some other things first.
gnome-keyring can live with pinentry as a PDEPEND.
(In reply to Gilles Dartiguelongue from comment #9) > gnome-keyring can live with pinentry as a PDEPEND. But, won't the problem still exist due to gcr/pinentry having a circular dep between them?
[master 6ecfa99] gnome-base/gnome-keyring: Pull pinentry in PDEPEND (#570512) 1 file changed, 82 insertions(+) create mode 100644 gnome-base/gnome-keyring/gnome-keyring-3.18.3-r1.ebuild Can you retry with this?
(In reply to Pacho Ramos from comment #11) At the tinderbox I do suffer from this since eons : * Error: circular dependencies: (app-crypt/pinentry-0.9.7:0/0::gentoo, ebuild scheduled for merge) depends on (app-crypt/gcr-3.18.0:0/1::gentoo, ebuild scheduled for merge) (runtime) (app-crypt/gnupg-2.1.12:0/0::gentoo, ebuild scheduled for merge) (buildtime) (app-crypt/pinentry-0.9.7:0/0::gentoo, ebuild scheduled for merge) (buildtime) * Note that circular dependencies can often be avoided by temporarily * disabling USE flags that trigger optional dependencies. last test was 2 min ago :-(
(In reply to Kristian Fiskerstrand from comment #7) > (In reply to Pacho Ramos from comment #1) > > This was introduced when fixing bug 560322, but it looks like, if needed and > > compile time, we won't be able to move the dep to PDEPEND :S > > Does gcr really require gnupg at build time? in what way does it invoke > gnupg? I have seen Fedora is not pulling gnupg for gcr... then, maybe double checking this would be interesting :)
[master 6295d86] app-crypt/gcr: gnupg is not really needed by gcr, this also prevents a circular dep issue (#570512) 1 file changed, 1 deletion(-)
(In reply to Pacho Ramos from comment #14) > [master 6295d86] app-crypt/gcr: gnupg is not really needed by gcr, this also > prevents a circular dep issue (#570512) > 1 file changed, 1 deletion(-) Maybe PDEPEND="app-crypt/pinentry[gnome-keyring]" can be removed from gnome-keyring ebuilds then? This is really unwanted dependency in some cases.
(In reply to Andrew Savchenko from comment #15) > > Maybe PDEPEND="app-crypt/pinentry[gnome-keyring]" can be removed from > gnome-keyring ebuilds then? This is really unwanted dependency in some cases. Any progress on that comment? I'm having a problem where a setup without gnome would require to set app-crypt/pinentry[gnome-keyring] which does not make much sense.
