boost @1.65.1_3 depends on itself

[mndavidoff (Monte Davidoff)]

Commit 83080c8 seems to have introduced a circular dependency on boost via py27-numpy.

$ port rdeps boost | grep boost
The following ports are dependencies of boost @1.65.1_3+no_single+no_static+python27:
                    boost

boost -> py27-numpy -> gcc7 -> cctools -> llvm-5.0 -> cmake -> curl -> libpsl -> gtk-doc -> source-highlight -> boost

The full output of port rdeps boost is attached.

[mamoll (Mark Moll)]

I added that numpy dependency. We can of course easily undo this, but then what gets installed when someone installs boost with non-default variants will depend on whether someone has numpy installed. Boost will automatically compile the numpy library when it's detected at build time. That's not ideal either. I'd actually like to use this library in another project, so I lean in favor of enabling numpy support, but that leads to this circular dependency. If we want to disable it, we'll have to patch the Boost code to remove the numpy check.

[mndavidoff (Monte Davidoff)]

Perhaps have two ports, boost and boost-numpy.

The boost port would install everything except the numpy library, even if it was built (e.g., in a Portfile post-destroot step, remove the numpy library if it was there). The boost port would not depend on pyXY-numpy.

The boost-numpy port would depend on boost and pyXY-numpy. It could rebuild boost but install only the numpy library. Rebuilding boost is admittedly inefficient, but it's better than not being able to install boost due to a circular dependency or not having the boost numpy library installed when it's needed. Perhaps at some later time boost could be patched to avoid rebuilding all of boost.

[michaelld (Michael Dickens)]

A few thoughts here:

1) I am becoming more and more convinced that for openmaintainer ports with owner(s), someone wishing to make a potentially non-trivial change -- virtually anything except a rev-bump -- should either open a PR or an issue describing the problem and solution. The usual "24 hour timeout window before committing any such change" would apply. In this manner, we port maintainers are given a chance to test out any such changes and approve or not of them. We might not be able to catch every single issue, but at least we're given a chance to do so. I, for one, will do this MO from here on, even though I know it's not what the Committers' Guide says about openmaintainer ports.

2) We need to do -something- pretty quickly. Reverting isn't really a good option since Boost will use NumPy if found & we don't want that. Let's try to fix the issue.

3) I like Monte's idea, but not for Boost itself. Much easier would be to split off libpsl's docs to be their own subport, say libpsl-docs; who actually uses local docs anymore? Add a note to libpsl about how to get its docs. On my laptop, it takes 22 seconds to fetch and build libpsl; a pittance compared with boost.

[mamoll (Mark Moll)]

I have attached a patch. Testing it now.

[mamoll (Mark Moll)]

@michaelld, in hindsight it definitely would have been better to have created a PR first. Sorry about that.

[mndavidoff (Monte Davidoff)]

Michael, I like your idea of creating a libpsl-docs port. (BTW, I use local docs when I need to refer to them frequently.)

[michaelld (Michael Dickens)]

@mamoll: Thanks. I'm sure you've experienced this too (and, not the first time for me), that I'm not alone in my wondering whether (1) would be a better MO for these situations.

[michaelld (Michael Dickens)]

I've attached a patch for libpsl, that splits off docs. It's pretty simple & works nicely for me & fixes this issue. Please test & verify on your setups. I'm adding on the owner of the libpsl port, too.

[michaelld (Michael Dickens)]

@dbevans: I'm proposing splitting off docs from libpsl, and have attached a patch that does this.

[mamoll (Mark Moll)]

@michaelld, I created a PR here: ​https://github.com/macports/macports-ports/pull/1309 It solves the circular dependency problem. An argument could also be made that having numpy support enabled by default would pull in too many other dependencies.

[michaelld (Michael Dickens)]

@mamoll: Cool thx I'll check it out. I do agree that adding in NumPy adds more dependencies that desired. Maybe we do both solutions to make it that much more robust? Worth considering.

[mamoll (Mark Moll)]

I am not sure what you mean by do both. Instead of a numpy variant, we could add a boost-bumpy subport that enables numpy support and in the post-destroot phase removes everything but ${prefix}/lib/libboost_numpy-mt.dylib / ${prefix}/lib/libboost_numpy3-mt.dylib (depending on which python variant was selected). We'd need to make sure that boost_numpy uses the same python variant as boost in that case.

[michaelld (Michael Dickens)]

"both" meaning your boost-numpy and my libpsl-docs ports. That way there are 2 ports that split off the cycle, not just 1.

It's easy to add in variant same-same checking to make sure the same Python is used for both boost and boost-numpy. I'll work on this shortly.

[michaelld (Michael Dickens)]

The patch is '-p1', by the way. I just updated it with the correct description for the subport.

[mndavidoff (Monte Davidoff)]

@michaelld: I tested the libpsl patch. It worked well. I reinstalled libpsl and installed libpsl-docs without any dependency cycles.

[michaelld (Michael Dickens)]

@mndavidoff: great! thanks for the feedback. not sure which way we'll go, but we'll decide soonish.

[michaelld (Michael Dickens)]

In 4f291a71ee38b58407f0ad141ad88c9591de51f7/macports-ports:

libpsl: split off docs to subport libpsl-docs .

• Maintainer timeout of > 24 hours to review and comment.
• breaks a port dependency cycle: #55807

[michaelld (Michael Dickens)]

I went ahead and committed the libpsl split, since it does fix this issue.

That said, given the number of dependencies added by py*-numpy, I'd like for @mamoll to keep pushing that split too. The challenge will be how to deal with the variants: do -all- variants have to be the same for boost-numpy as for boost itself: the same +clang (if selected), +*mpi* (if selected) (etc)? I don't know, but the safest way to go is to make sure the variants are identical between these ports ... which seems like a lot of work. Maybe someone else has some wisdom here?

[michaelld (Michael Dickens)]

This issue was fixed in 2 different ways. Closing this ticket.