"concurrent" qt4-mac: request feedback & testing for current port phase in Portfile?

[Lawrence Velázquez]

On Dec 11, 2014, at 9:21 AM, René J.V. Bertin <rjvbertin at gmail.com> wrote:

> Yes,  I have willingly not provided a mechanism to avoid breakage of ports installed against +concurrent.
> But remember that I did try to set +concurrent by default if qt4-mac is installed that way.

We have to consider all cases, not just new installs.

Please don't go down this road. Every time anyone's ever said "hey I know, let's try depending on variants", it *inevitably* leads to pain and suffering. Don't repeat history.

>> There are but a few of the problems with attempting to use a variant as something that can be depended upon, which is why I don't like doing it.
> 
> Again, it is not my intention to use a variant as a definitive solution, or some similar solution.

So why not try doing it right from the start?

> Note that it isn't necessarily required to bump the dependent port revisions. When +libsymlinks isn't used, the rev-upgrade check will cause all dependent ports to be rebuilt anyway ... and I presume port will pull in binary installs when they exist in that case (?)

Don't rely on rev-upgrade in lieu of proper revbumping. Don't assume that everyone uses binaries.

> There's also the point of +libsymlinks, the backwards-ABI-compatibility variant. Will it be provided so that people don't have to rebuild all ports not available as binaries the moment the change is pushed through? Should we instead provide a (sub)port only creates the symlinks

Wouldn't the dependents have to be revbumped anyway to make sure that they are depending on this shim port? Then they'd have to be revbumped a second time to switch over to the hypothetical qt4-mac Mk 2.

vq