[Bug 272510] graphics/gd and graphics/openexr form a circular dependency loop with some options

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272510

            Bug ID: 272510
           Summary: graphics/gd and graphics/openexr form a circular
                    dependency loop with some options
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: ports-bugs@FreeBSD.org
          Reporter: nicholas.e.taylor@gmail.com
                CC: dinoex@FreeBSD.org, mandree@FreeBSD.org
                CC: dinoex@FreeBSD.org, mandree@FreeBSD.org

Short version: graphics/gd options AVIF and HEIF add a dependency on
graphics/openexr; graphics/openexr option DOCS adds a dependency on
graphics/gd.  I'd like to break that circular dependency or mark those options
as incompatible, and have no idea how.

Longer version: the AVIF option of graphics/gd is marked as BROKEN: circular
dependency loop.  In a fit of procrastination I decided to chase that loop
down.  In the process I found that the HEIF option introduces the same circular
dependency loop and is not marked as BROKEN.

The core of the problem seems to be that devel/doxygen depends on graphics/gd,
which is sensible: gd is a useful tool for generating documentation.  A lot of
ports that build documentation also depend on devel/doxygen, again sensibly. 
This is only a problem when a port on which graphics/gd depends builds
documentation using doxygen.  In this case graphics/openexr uses
devel/py-breathe to build its documentation, which in turn uses doxygen.

In this case unsetting DOCS on graphics/openexr is sufficient to break the
dependency loop, but I don't know how to express "these two options in
different ports are incompatible" so that no-one else needs to walk through
dependency trees.

In the general case building the documentation for a package is a completely
different task from building the package itself, and ports that are useful for
building documentation are going to suffer this class of dependency loop unless
there's some way to separate out documentation-like dependencies from
package-like dependencies.  Is there one that I've missed?

-- 
You are receiving this mail because:
You are the assignee for the bug.