Bug 250945 - security/pinentry-gnome3: dependency loop
Summary: security/pinentry-gnome3: dependency loop
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Jason E. Hale
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-08 10:54 UTC by Stéphane D'Alu
Modified: 2020-11-18 22:13 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (jhale)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stéphane D'Alu 2020-11-08 10:54:14 UTC
Trying to build with poudriere, a depency loop is detected

[00:00:30] Error: Dependency loop detected:
These packages depend on each other: pinentry-gnome3-1.1.0 gcr-3.38.0 gnupg-2.2.23 pinentry-1.1.0_6
Comment 1 M. Voorhis 2020-11-09 17:35:09 UTC
synth also exits due to this loop:

security/gnupg scan aborted because a circular dependency on security/gnupg was detected.
... backtrace security/gcr
... backtrace security/pinentry-gnome3
... backtrace security/pinentry
... backtrace security/gnupg
Comment 2 M. Voorhis 2020-11-09 18:18:08 UTC
I have two different 12.2-STABLE machines with different copies of the ports tree (same svn revision though -- 554783).

Importantly, "make index" fails on one machine and NOT on the other.

I will replace the ports tree on the makeindex-failing machine and re-run the index build there to see if the copy of the ports tree is the thing that's actually broken.
Comment 3 M. Voorhis 2020-11-10 02:04:36 UTC
(In reply to M. Voorhis from comment #2)

Duh, the pinentry on the working machine didn't have GNOME3 selected as an option.  The default settings for pinentry have GNOME3 shut off.
Comment 4 commit-hook freebsd_committer freebsd_triage 2020-11-15 20:38:32 UTC
A commit references this bug:

Author: jhale
Date: Sun Nov 15 20:37:59 UTC 2020
New revision: 555432
URL: https://svnweb.freebsd.org/changeset/ports/555432

Log:
  security/pinentry: Users who enable the non-default GNOME3 option will now
  have to install security/pinentry-gnome3 manually. This has been done to break
  a dependency loop that was introduced in r553735 where security/gcr added a
  build dependency on security/gnupg.

  Before r553735:
  security/gnupg -> security/pinentry -> security/pinentry-gnome3 -> security/gcr

  After r553735:
  security/gnupg -> security/pinentry -> security/pinentry-gnome3 -> security/gcr
  -> security/gnupg

  Now:
  security/gnupg -> security/pinentry
  security/pinentry-gnome3 -> security/gcr -> security/gnupg

  A pkg-message has been added to remind users of the GNOME3 option to install the
  required package manually and to deinstall it if no longer needed.

  PR:		250945
  Reported by:	<sdalu@sdalu.com>

Changes:
  head/security/pinentry/Makefile
  head/security/pinentry/pkg-message.gnome3
Comment 5 Jason E. Hale freebsd_committer freebsd_triage 2020-11-15 20:45:48 UTC
This dependency loop was caused by an update to security/gcr (r553735). I have removed the security/pinentry-gnome3 dependency from security/pinentry, but users of the GNOME3 option will have to install it manually now.
Comment 6 Charlie Li freebsd_committer freebsd_triage 2020-11-18 21:49:30 UTC
Since security/gcr only needs some gnupg instance during the build, it may be better to specify security/gnupg1 as a BUILD_DEPENDS there. This is what I have been running with ever since I've started dogfooding security/gcr 3.36.

Otherwise, this commit breaks building security/gnupg at all when GNOME3 option is selected.
Comment 7 Charlie Li freebsd_committer freebsd_triage 2020-11-18 22:13:35 UTC
Alternatively, the RUN_DEPENDS in security/gnupg can be adjusted to pinentry>0:security/pinentry to check for the package rather than checking for the "executable".