depends_run and activation

[Ryan Schmidt]

On Mar 17, 2021, at 05:19, René J.V. Bertin wrote:

> On Tuesday March 16 2021 23:12:12 Ryan Schmidt wrote:
> 
>> There is no such thing as a "too-new version". There is only one version of a port available in the ports tree -- the current version.
> 
> Sure, but anything that's in the current port tree should not be authoritative over what is currently installed. It it were, you'd have a hard time keeping retired ports alive, for instance.

I don't really follow what you're saying. The ports tree is authoritative. There is only one version of a port in the ports tree. If by retired ports you mean ports that have been removed from MacPorts, then MacPorts is not designed to accommodate continuing to use them (though of course in some cases they continue to work).

>> If you install a port, MacPorts will first install or upgrade any of that port's dependencies.
> 
> For upgrading that makes sense. It does not for activating a non-current version. The MacPorts devs who designed the de/activation feature must have had good reasons for introducing it, and users can have very good reasons to keep older versions of a port around. Audacity is among my own official ports (the upcoming version will use a new project file format that older versions can't read).
> For activating an older version it would make sense to offer to activate the versions of the dependency ports that were installed when the target port was installed.

I don't believe we can do that because I don't believe that information is stored in the registry. 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.

> That's just an observation btw (which one can extend to variants - wouldn't it be great if you could activate the +quartz instead of the +x11 version of a GTk port and have all dependencies be adjusted as required?)

Not really. All ports in a MacPorts installation must use x11 or quartz. You can't decide to change which you use after you already have ports installed. 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.

>> I assume that MacPorts handles re-activation of a port the same way that it handles installation of a port with regard to upgrading dependencies.
> 
> As said above, it shouldn't and should actually do the opposite. Imagine that you're reactivating the last (older) version of a port to support 32bit, or more fashionable, the last to support Intel architecture. You wouldn't want that to cause its dependencies to be upgraded/activated to a version that dropped support for that particular architecture. 

Well I'm not certain what activate does, I was just speculating. You can test it if you like. We want to offer useful software. If the current version of a port (let's say foo @4.0.0) has removed a feature, like 32-bit support or whatever that someone finds useful, then it should be re-added as a new port (e.g. foo3 @3.2.3). Activating old versions of ports for long-term use is not an intended use of MacPorts.