xorg-libxcb : destroot weirdness

[RJVB (René Bertin)]

port:xorg-libxcb has a build dependency on python which AFAICS is actually a build dependency on port:xorg-xcb-proto.

I noticed a little weirdness when upgrading my libxcb port, which I have installed +universal. As often, I ran a port build and only did the port destroot when the build succeeded.

I do not have a universal version of the selected python port installed, and was served with a request to install the port only when I executed the libxcb destroot step (as usual, no indication that this was actually a "request" to install the universal variant of the dependency!).

Two things: 1) installing a build dependency only for the destroot step is a little late and in this case proof that 2) a build dependency on python because python scripts are used does not (normally) require a universal python interpreter, so for this port there can be an additional depends_skip_archcheck-append line that adds all the possibly required pythonXY ports.

(and as a side-note, I really don't see why good old Python 2.7 wouldn't be used as long as upstream doesn't require a v3 interpreter. Saves some pointless updating when a new 3x version becomes the default.)

[ryandesign (Ryan Carsten Schmidt)]

Replying to RJVB:

port:xorg-libxcb has a build dependency on python

Yes, on one of several different versions of python 3, depending on the chosen variant.

which AFAICS is actually a build dependency on port:xorg-xcb-proto.

I'm not sure what you mean.

xorg-libxcb does also declare a library dependency on xorg-xcb-proto.

xorg-xcb-proto does also require a version of python, and does also offer python 3 variants for that purpose.

I noticed a little weirdness when upgrading my libxcb port, which I have installed +universal. As often, I ran a port build and only did the port destroot when the build succeeded.

I do not have a universal version of the selected python port installed, and was served with a request to install the port only when I executed the libxcb destroot step (as usual, no indication that this was actually a "request" to install the universal variant of the dependency!).

Two things: 1) installing a build dependency only for the destroot step is a little late and in this case proof that

I cannot explain why that would have happened for you. MacPorts knows that build dependencies are needed at build time, which includes the configure, build, and destroot phases. If you asked to configure or build or destroot a port, MacPorts would have upgraded dependencies first, including reinstalling any non-universal ports as universal if needed.

2) a build dependency on python because python scripts are used does not (normally) require a universal python interpreter, so for this port there can be an additional depends_skip_archcheck-append line that adds all the possibly required pythonXY ports.

Yes, I suppose that could be added to xorg-libxcb and probably also xorg-xcb-proto.

(and as a side-note, I really don't see why good old Python 2.7 wouldn't be used as long as upstream doesn't require a v3 interpreter. Saves some pointless updating when a new 3x version becomes the default.)

python27 is EOL, so we are trying to move ports to non-EOL versions of python 3 wherever possible. The python27 variant was removed from xorg-libxcb in [ebf645f6789d57183fef6a525cff1a31e19349aa/macports-ports] and was removed from xorg-xcb-proto in [ae53b6b0f446bfb57eeedaa778c3895974c0a665/macports-ports] and should not be re-added. You will not encounter "pointless updating when a new 3x version becomes the default" because you will continue to use whatever version of python you have selected using the variant.