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. >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. 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?) >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. >Have you run portindex in the root of that ports tree, such that the >newly-added dependency is in the index? If not, that might explain it. Seems I still haven't so I suppose I can still check if this indeed makes a difference. R.
