[MacPorts] #69895: base does not handle dependencies correctly from tests variant

[MacPorts]

#69895: base does not handle dependencies correctly from tests variant
---------------------------+--------------------
  Reporter:  barracuda156  |      Owner:  (none)
      Type:  defect        |     Status:  new
  Priority:  Normal        |  Milestone:
 Component:  base          |    Version:  2.9.3
Resolution:                |   Keywords:
      Port:                |
---------------------------+--------------------

Comment (by ryandesign):

 Replying to [comment:4 barracuda156]:
 > I still do not understand why the base considers that a dependency
 cycle,

 MacPorts base doesn't contain any code that "considers" something to be a
 dependency cycle. Rather, MacPorts base was designed under the assumption
 that dependency cycles do not exist. If that assumption is violated,
 behavior is undefined. Anything could happen. MacPorts base might do what
 you want or it might not.

 Imagine port R-foo depends on port R-bar and R-bar depends on R-foo. (I'm
 referring to dependencies that affect installation, like depends_build or
 depends_lib, not depends_test.) That's a dependency cycle. It cannot be
 satisfied. Imagine MacPorts base trying naively to install R-foo. It finds
 that R-foo depends on R-bar so it tries to install R-bar first. It then
 looks at R-bar, finds that it depends on R-foo, so it tries to install
 R-foo first. And so on forever. Infinite loop.

 I've never observed MacPorts get into an infinite loop so I assume it must
 contain some safeguard against that, probably for performance reasons.
 Imagine that both R-foo and R-bar also depend on R-CRAN-recommended. It
 would be a waste of time for MacPorts to check twice whether it still
 needed to install R-CRAN-recommended so it probably keeps track of ports
 it has already considered. So now, when asked to install R-foo, it checks
 its dependencies. Let's say R-CRAN-recommended is already installed so
 then it looks at the other dependency, R-bar, which isn't installed yet,
 so it checks its dependencies. It finds that R-bar depends on R-CRAN-
 recommended, which is already installed, and R-foo, which isn't installed
 yet but it has already checked R-foo's dependencies, therefore it must be
 time to install R-foo, so it does, even though its dependency R-bar has
 not been installed yet. It would have been if the dependency cycle had not
 existed. I have not read the MacPorts base code so I do not know if this
 accurately describes what it does but it is the behavior you observed and
 the explanation seems logical to me.

 > since it is not (a real dependency cycle makes installation impossible,
 but it is not the case with test dependencies),

 I'm imagining that one of the test dependencies eventually depends on the
 port being tested, hence a cycle. I cannot see such a cycle with the ports
 on my system but perhaps you have other local modifications that introduce
 such a cycle.

 > and it was working at some point correctly,

 That's the tricky thing with dependency cycles. If you already have one of
 the ports in the cycle installed, you won't notice the problem. That's how
 cycles get inadvertently introduced into MacPorts. "It was working", and
 then someone adds a dependency to one port, not realizing that the
 dependency they just added eventually depends on the port they added the
 dependency to.

-- 
Ticket URL: <https://trac.macports.org/ticket/69895#comment:8>
MacPorts <https://www.macports.org/>
Ports system for macOS