depends_run and activation

[Ryan Schmidt]

On Mar 17, 2021, at 06:38, René J.V. Bertin wrote:

> On Wednesday March 17 2021 05:28:29 Ryan Schmidt wrote:
> 
>> I don't believe we can do that because I don't believe that information is stored in the registry.
> 
> Probably not, given that MacPort doesn't do versioned dependencies. In itself that doesn't mean that it couldn't store the versions of all dependencies that were active (or current) when a port was installed, of course. (And with the registry being a database I presume such changes can be made anytime?)

Yes, it could be done. I'm not convinced that it should be done.


>> And it could break other ports to reactivate old versions of dependencies, so we don't want to make it too easy or automatic to do so.
> 
> But wouldn't it be easier to undo such damage if this were all automatic, rather than having to fix your mess-up by hand?

I think your proposal would result in a lot of unnecessary activations of older dependencies which could have consequences for other ports.

For example, suppose zlib 1.2.12 is released today which is compatible with previous versions but fixes a long-standing bug, and we update to that version in MacPorts. Everything you installed in MacPorts before today that depends on zlib is, in your proposal, recorded as having been built with an earlier version of zlib. Therefore if you reactivate an old version of a port, it reactivates zlib 1.2.11, reintroducing the bug that 1.2.12 fixed, not only for the port that you were trying to use the older version of but also for all other ports, even though they would all have been compatible with zlib 1.2.12.

Or there's the scenario where the library version changes. If I update ImageMagick to 6.9.12-3 today, that will change its major library version and I will have to revbump everything that links with it. If you then go and reactivate an old version of a port that links with ImageMagick, it will, in your proposal, reactivate the old ImageMagick. Certainly that is necessary for the old version of that port to work, however it will also break any other ports you have installed which link with ImageMagick, which you might not have been expecting.


>> It was really a mistake for us to have implemented the choice as variants. Implementing it as subports would have been better, but that was understandably not done since the subport feature did not exist at the time.
> 
> No, I think that would actually have been worse, unless you mean with the added help of a PortGroup, and GTk-x11 and GTk-quartz installed in separate sub-prefixes.

Yes, I was suggesting that the x11- and quartz-flavored subports would be simultaneously installable, whether in separate prefixes or just different filenames, and yes, some assistance from a portgroup to do that would not be unreasonable.