Revisiting the idea of "pinning" ports

Gregorio Litenstein g.litenstein at gmail.com
Mon Oct 2 17:46:33 UTC 2023


I know this has been askeed AT LEAST once before. I know the reason why macports doesn't allow "pinning" ports or choosing older versions and, while a frequent source of frustration for me, I can agree it's a sensible approach.

So, what's this about?

More than pinning per-se, I'm wonndering if it'd be feasible to add some mechanism to opt-out from updates/rebuilds of outdated ports in some specific cases.

Which cases? I have one in mind, possibly two.

Chiefly, if a port is outdated but wasn't requested explicitly by the command running and is strictly a build-time dependency for what the user wants.

And possibly, this could be extended to transitive dependencies.

Why?

It's possibly an uncommon scenario to be in, but I have come to dread running port upgrade or selfupdate, because 8/10 times, it ends with me having to rebuild gcc, rust and cargo, which together take several hours and in my workflow are strictly build-time dependencies 99% of the time.

Am I making any sense? Would such a thing be feasible?


Gregorio Litenstein Goldzweig
Médico Cirujano


• Fono: +56 9 96343643
• E-Mail: g.litenstein at gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20231002/9b8d86da/attachment-0001.htm>


More information about the macports-dev mailing list