Ensure the default dependency is active, not a path-based alternative

[ryandesign (Ryan Carsten Schmidt)]

asl failed to build:

​https://build.macports.org/builders/ports-11_arm64-builder/builds/107433/steps/install-port/logs/stdio

dyld: Library not loaded: /opt/local/lib/libicui18n.73.dylib
  Referenced from: /opt/local/lib/libxml2.2.dylib
  Reason: image not found

icu-devel was just updated to 74.1. icu is still at version 73.2.

Nothing in asl's dependency chain depends on icu-devel. (I can't find any port that does.) Yet apparently icu-devel, not icu, was active.

​The build preceding this one is where the commit that updated icu-devel was handled. icu was deactivated, icu-devel was built.

Is this a bug in mpbb? libxml2 depends on path:lib/pkgconfig/icu-uc.pc:icu so icu-devel satisfies it but since icu's install_name keeps changing with each major release it's not really a drop-in replacement. Maybe mpbb should ensure that the default dependency (in this case icu) is active, and not one of the path-based alternatives?

Or is the bug that ports like icu whose install_name keeps changing should not be depended upon using path:-based depspecs?

[jmroot (Joshua Root)]

This does mirror the experience a user will have if they install icu-devel and then install an icu dependent from a binary archive. So yes, I would say path deps should be avoided in such cases. Simply always installing the port named in the depspec would not mirror what happens for users, as the path can be anything on the system, not only something provided by a port.

[ryandesign (Ryan Carsten Schmidt)]

Well then limit my remarks to those path:-based depspecs that do refer to files installed by ports, i.e. most cases.

If we say that icu dependents must not use path:-based depspecs, that makes life much more difficult for the maintainer of the icu ports who might like to test building a variety of ports against a new version of icu-devel to verify they still work before updating the icu port.

We don't intend the buildbot to exactly mirror what happens on a user system. If we did, we wouldn't bother deactivating all but essential deps before a build. But we do that to avoid the pretty common problem that some ports can't build with certain other ports active, or that some ports might opportunistically use other ports that they don't declare dependencies on. By having only the declared deps active on the buildbot, we avoid a whole set of build problems, and can then publish binaries which users use, and then they won't experience those problem either. This is good for the user. We could have the buildbot do the same for path:-based deps to avoid the inevitable situation where ports that were presumed to be drop-in replacements turn out not to be. Consider any number of cases where a new version of software may behave differently from the old version in some way that causes a build failure for another port.

[ryandesign (Ryan Carsten Schmidt)]

Or maybe icu should adopt the boost model of separate ports for each major version.

[jmroot (Joshua Root)]

I understand that testing -devel ports for binary-incompatible new versions is a real problem, but path: dependencies are really not a good solution to it.

[jmroot (Joshua Root)]

However I'm not sure exactly what happened here, as this should already be doing basically what you want: ​https://github.com/macports/mpbb/blob/master/tools/dependencies.tcl#L140

[jmroot (Joshua Root)]

Looks like a bad interaction with path: deps and the cleanup step. This shows icu-devel being uninstalled: ​https://build.macports.org/builders/ports-11_arm64-watcher/builds/39111/steps/cleanup/logs/stdio

But libxml2 was still active and left that way, as it's not seen here: ​https://build.macports.org/builders/ports-11_arm64-builder/builds/107433/steps/install-dependencies/logs/stdio

I would guess this is because the registry does not consider libxml2 a dependent of icu-devel, because it was built against icu. It's important to deactivate the dependents of any ports that are deactivated or uninstalled, because mportdepends stops as soon as it sees that a dep is active, it doesn't continue to check recursive deps.

[jmroot (Joshua Root)]

In 4dc59540c3ec9f77b15c5fbb09ea7b5944272cd9/mpbb (master):

cleanup: deactivate ports with inactive dependencies

Fixes: #68662