Port trees for specific versions of MacOS

[René J.V. Bertin]

On Wednesday March 28 2018 09:44:07 Ken Cunningham wrote:

> Pegged supporting libraries, like libvpx, are harder as often in the main port tree the use of them on certain systems is dropped -- can't ask for anything different. Interested users will have to step up.

I'm not sure I follow nor that I agree with what I think I understand. If pegged ports are ports no longer supported (in that form/version) on the main tree, why would they have to follow what the main tree does with their current version?
libstdc++ would be a prime example of that: apparently the main tree will drop it as a dependency of other ports in a nearish future. Legacy port trees for libstdc++ based systems shouldn't follow that move, evidently?

I agree that interested users would have to step up, anyway.

> Open to opinion on the optimal method, but so far, I've set it up that each OS port tree overlay is freestanding, just to keep my mind clear.

That's the approach I had in mind too at first, until I realised that the last non-C++11 version of a port would be the last version in the trees for everything up to 10.8 . You only have to copy them once, but if you do have to go in later it's easy to forget a copy or 2, or mess something up otherwise.
OTOH, users would need to set up the trees list once and for all, and could be helped by a script.

> It needs a bit of cleanup every once in a while, as things change in the main repo and I don't notice necessarily instantly.

I face the same situation with a local mod of mine, where I avoid having to rebuild after upgrading a dependency by preserving the shared library runtimes (libfoo.*.dylib). That's cumulative and after a while certain ports carry a number of truly obsolete versions.


BTW: such legacy trees could also be useful for people who develop and package targeting legacy systems.

R.