port upgrade outdated order

[Clemens Lang]

Hi *,

please stop spamming so fast, I can't keep up with the responses.

----- On 4 Mar, 2015, at 17:52, René J.V. Bertin rjvbertin at gmail.com wrote:

> On a related note: it'd be nice if MacPorts could be a little bit more proactive
> in deactiving conflicting ports. Like when installing a subport that conflicts
> with one of its siblings. If both are at the same version I don't see why `port
> install foo-B` wouldn't cause the automatic deactivation of port:foo-A as long
> as foo-A doesn't provide anything others depend upon that foo-B doesn't
> provide. Same for say qt5-mac and qt5-mac-devel, which are interchangeable but
> cannot be installed at the same time. If I install or activate the one, the
> other could be deactivated automatically.

MacPorts doesn't do this and shouldn't. 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. If you had qt5 installed and exchange it for
qt5-devel, all ports that depend on qt5 are now potentially broken. In this case,
rev-upgrade will probably detect and attempt to fix this for you, but that's only
the case for libraries – there might be other subtle things where this doesn't
work.

> (just to be sure, if you declare a path: style dependency, the provided path is
> recorded in the registry, right?)

No, the port is, for precisely the reason above.


----- On 4 Mar, 2015, at 18:32, Chris Jones jonesc at hep.phy.cam.ac.uk wrote:

> I am not sure I see the need for ports to be able to opt in or out of
> tracemode (out should be just not possible, but I could be persuaded
> on opting in).

Ports that are known to not work in trace mode because of how trace mode
works should be able to opt-out. One example of this is go, which does not
build when DYLD_INSERT_LIBRARIES is set.


----- On 4 Mar, 2015, at 18:39, Chris Jones jonesc at hep.phy.cam.ac.uk wrote:

> Hmm, I did not realise this. I thought that it was the opposite way
> around, so only files explicitly registered are made visible. Whats the
> reason it doesn't work this way ? Some technical limitation or by choice
> (for some reason I don't yet see) ?

Initially, I did this, then quickly noticed that there's lots and lots of
cache and configuration files not registered to any port but were still
needed to build dependents.

Obviously, that's a theoretical flaw in trace mode, but only a theoretical
one at that. In practice, it turns out that while some caches might contain
data on files that would be hidden by trace mode, the builds still fail if
the files are actually opened and needed. For example, GHC's cache isn't
registered to any port and contains a list of all installed haskell
packages – if a port has an undeclared dependency on them it will still fail
in trace mode, though. The error message changes from "this package isn't
installed" to "this package is broken, because some of its files are
missing", but we don't really care about that, especially since we get a
diagnostic list of accessed-but-denied files at the end.


-- 
Clemens Lang