Re: Port trees for specific versions of MacOS

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Port trees for specific versions of MacOS

René J.V. Bertin
On Wednesday March 28 2018 09:00:52 Ken Cunningham wrote:

Thanks for picking this up,

> I'd just like to mention that I've been working on this on my own for a while now, and have such trees in place, and available for contributions.  Anyone interested, feel free to suggest or contribute, please.

How much extra work would you say this represents, assuming you only do the minimal corrective maintenance once ports get "frozen"?

Also, what's the exact approach? Do users of, say, 10.8 only specify the 10.8 overlay tree before the usual ports tree, or do they specify the whole series (say, 10.8 - 10.7 - 10.6)? The latter approach would dispense you of having to copy all those ports requiring C++11 in all overlays (but more could go wrong on user machines?)

R.
Reply | Threaded
Open this post in threaded view
|

Re: 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.
Reply | Threaded
Open this post in threaded view
|

Re: Port trees for specific versions of MacOS

Ken Cunningham

On 2018-03-28, at 10:04 AM, René J.V. Bertin wrote:
>
> 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?

e.gl. things like this, from ffmpeg:

    # as of 1.6.0 libvpx only supports darwin 10 or later
    if {${os.major} < 10} {
        depends_lib-delete port:libvpx
        configure.args-replace --enable-libvpx --disable-libvpx
    }




I actually have a pegged libvpx for 10.4 and 10.5 in the repo. So if someone wanted to optimize this, they would have to look into that.


Ken