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
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
