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.
