port upgrade outdated order

[Chris Jones]

On 04/03/15 11:29, René J.V. Bertin wrote:
> On Wednesday March 04 2015 10:51:06 Chris Jones wrote:
>
>> Personally, I think what it does is *always* correct.
>
> Aren't you relying on the assumption that all ports register all the files they install?

yes. If they don't that should be regarded as a bug.

  What happens to files installed because of some port C that are used 
by port A while it builds, how are you going to block them if port C is 
not on the dependency list?

If port C is not listed as a dependency of port A, and port A then uses 
files from port C, then that is a bug in port A.

> There were discussions not that long ago that showed that there are classes of files that get installed by ports but not registered for a reason.
>
>> So no, I don't personally think there should be a way for ports to opt
>> in or out.
>
> So to you it's OK if a port fails to build because it pulls in things from an earlier, installed version of itself that were not blocked because the feature was not enabled, and do so without as much as an explanation?

Thats not what I said.

All I am saying is a port build should be *completely* reproducible and 
predictable. What happens during the build of a port should not depend 
on either anything from an older currently installed version of that 
same port, or from any ports which the port in question finds at build 
time and uses, but has not declared a dependency on.

trace mode, which blocks access to files a port should not be using 
(because they have not declared a dependency) is a great tool at 
providing this reproducibility. I do not see any use case for an 
individual port being able to by itself opt in or out of this feature, 
it should be completely up to the user running port to decide, either 
via a command line switch, or via macports.conf. I would not be in 
favour of ports being able to forcibly opt out, as the only reason for 
doing so in my opinion is because they have bugs that should instead be 
fixed.

Chris
>
> I'd be in favour of a more pragmatic approach, and allow opt-in (require it) when the feature is disabled globally (in macports.conf, possibly with a warning), which turns to an error when the feature was disabled on the commandline. That's not unlike how dependencies are handled: nothing is done when they're already installed, they're installed when needed unless the user takes action to prevent that - in which case an error is raised at some point.
>
> R.
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>