On Dec 11, 2014, at 9:21 AM, René J.V. Bertin <[email protected]> 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 _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
