port upgrade outdated order
René J.V. Bertin
rjvbertin at gmail.com
Wed Mar 4 10:59:59 PST 2015
On Wednesday March 04 2015 17:32:59 Chris Jones wrote:
> > As to fixing ... the experience many of use have had with /usr/local can probably serve as an example/metaphor for why it's not always feasible to avoid including the wrong version of a header... (and I guess it should be easier to exclude or demote a directory from outside the prefix than to exclude/demote ${prefix}/include ...)
>
> I don't see whay you say its not feasible. tracemode would absolutely
> prevent access to /usr/local during building, which is a very good
Yes, of course - I meant outside of trace mode (or anything else that ensures that a build can access only the files it is allowed to and has to see).
@ larry
> Base doesn't have a concept of equivalence. It doesn't know that qt5-mac and
> qt5-mac-devel are interchangeable. We could implement virtual ports or
> something like that, but that's a rather larger project.
Would be more like Debian's "replaces", no?
@ Clemens
> There's an easy explanation: Let's assume
> while qt5 and qt5-devel provide different versions of the same software,
> they're still not binary-compatible.
Actually, Qt makes it a point to be binary compatible between point releases, but you have a point.
However, my initial argument concerned subports of one and the same main port, there ought not be ABI issues there.
Still, it's true that a keyword to signal equivalence (or a command line option to give a deactivation greenlight) would be better.
Mind you, Debian's implementation isn't exactly foolproof either... I've seen enough cases where packages aren't replaced for some reason, or where they're replaced and hell ensues.
R.
More information about the macports-dev
mailing list