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?) >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? >> 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. I wouldn't mind having "dangling" GTk dependent ports; the feature as I described would undoubtedly be able to correct those without having to hunt down all "wrong" dependencies. But you could also imagine the opposite approach, kind of like the port select mechanism where you'd activate either the x11 or the quartz variant of the common dependency (here, GTk) and have all ports flipped That would require a decision about how to handle ports that exist (are installed) only in one variant. >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. There are similar scenarios possible with Qt that I have been giving quite some thought over the past few years, though there the urgency is much less since Qt has good guarantees that binaries built against 5.x will run against 5.x+i .There's also a possible +quartz vs +x11 scenario, but that's extremely simple ... figure out how to build a qt5-x11 port (that installs just the X11 "backend") and suddenly most-if-not-all Qt5 applications can be started in X11 mode at runtime (from a terminal, at least) :) > Activating old versions of ports for long-term use is not an intended use of > MacPorts. I wasn't considering the use duration at all in my reasoning. In fact, my arguments are strongest (for me at least) for occasional use of that older version. If you're going to be using that older version for a long time then the overhead of having to figure out what other ports to re-activate is less important. (And in fact, I think this was one of the reasons for which I started my own ports tree - cutting down on the overhead of keeping things up-to-date). R
