base does not necessarily tell you when circular dependency occurs

[fvaccari]

When updating ports on 10.6 we seem to be lost in a cyclic dependency, but base doesn't seem too helpful communicating this information.

$ sudo port -v upgrade outdated
Warning: No port clang-9.0 found in the index.
Warning: No port legacy-support found in the index.
Warning: No port curl found in the index.
Warning: No port expat found in the index.
Warning: No port bzip2 found in the index.
Warning: No port libarchive found in the index.
Warning: No port libuv found in the index.
Warning: No port legacy-support found in the index.
--->  Computing dependencies for cmakeError: Problem while installing cmake
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

$ sudo port -d upgrade outdated
...
Error: Unable to exec port: too many nested evaluations (infinite loop?)
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

See the logs

[kencu (Ken)]

Well -- there doesn't seem to be any portindex of any use available...

sources.conf misconfigured?

totally messed repo?

[mojca (Mojca Miklavec)]

It's not a messed-up repository, it's simply a circular dependency. Please let Franco submit a PR to fix that circular dependency as an exercise ... but the base should at least tell you there's a circular dependency without the need to enter the debug mode.

[fvaccari]

In 9e7ab4d32e458323f54ec38ad736dc642013d128/macports-ports (master):

cmake: remove cyclic dependency on clang-9.0

See #59289
See #58821

[ryandesign (Ryan Carsten Schmidt)]

Indeed, ports shall not introduce circular dependencies; if they do, base behavior is not defined.

[cjones051073 (Chris Jones)]

Although in this case it was not really the port itself causing the problem, but base itself through the compiler selection it was making.

I am with Mojca, surely it shouldn’t be too hard for base to detect when this happens and give a reasonable error. Base is really the only place this check could be done. Its difficult for individual ports to know when this is happening.

[kencu (Ken)]

I would have thought a circular dependency would look more like this one, for a similar issue, earlier today 59279.

How is it that this one shows "no port in the index", and the other was so much more clear?

[jmroot (Joshua Root)]

Replying to cjones051073:

Although in this case it was not really the port itself causing the problem, but base itself through the compiler selection it was making.

Technically that choice comes from the ports tree, not base.

[cjones051073 (Chris Jones)]

Replying to jmroot:

Replying to cjones051073:

Although in this case it was not really the port itself causing the problem, but base itself through the compiler selection it was making.

Technically that choice comes from the ports tree, not base.

In this case the cmake port did not have a problem until an unrelated change elsewhere was made, adding a new compiler option. I find it hard to blame the port in this case.

In any case it really does not matter, assigning ‘blame’ is useless. The bottom line there is one place that could ever detect these circular dependencies, and that is in base, so that is the place that needs the protection or error reporting.

[mojca (Mojca Miklavec)]

My only concern is: debug mode did tell us it was a circular dependency, but the error did not even proliferate to verbose output.

All I'm asking for is for the error to show up to make it obvious what happened.

[JDLH (Jim DeLaHunt)]

I agree that base should surface the error information that there is a dependency cycle among ports. #59445 is another bug which appears to be caused by a dependency cycle. It manifested as an infinite loop in ./restore_ports.tcl during a Migration. Diagnosing the problem was harder because the base didn't highlight that there was a dependency cycle.

[jmroot (Joshua Root)]

In cea9833fd1f84475293be3201ba80fb8ad4c239f/macports-base (master):

Improve dep cycle handling and reporting

Fixes: #59289

[JDLH (Jim DeLaHunt)]

Does this fix improve the clarity of error messages from restore_ports.tcl, when the list of ports to restore have a circular dependency? If so, then this fix might also help #59445.

[cooljeanius (Eric Gallager)]

Replying to JDLH:

Does this fix improve the clarity of error messages from restore_ports.tcl, when the list of ports to restore have a circular dependency? If so, then this fix might also help #59445.

If it does, then the pull request I opened to address that might no longer be necessary: ​https://github.com/macports/macports-contrib/pull/10

[Dave-Allured (Dave Allured)]

Would someone with a test version of macports-base (master), please try these commands:

port rdeps py38-attrs
port rdeps --full py38-attrs

With 2.6.4, the first command currently prints 38 lines including a circular dependency only 2 levels down. There is no special warning; you would have to notice the duplicate by eye.

The second command goes to infinite loop with endless recursing console output, so don't run it on a hard copy terminal. ;-)

This is from unresolved issue #62277, but it is also a good test case for Joshua's current fix.

[jmroot (Joshua Root)]

This was about error reporting when installing or upgrading ports with a circular dep. The fix doesn't affect rdeps and I don't know if it affects restore_ports.tcl.

[Dave-Allured (Dave Allured)]

No problem. Thanks for explaining.