port upgrade outdated order

René J.V. Bertin rjvbertin at gmail.com
Wed Mar 4 09:29:06 PST 2015


On Wednesday March 04 2015 17:34:32 Mihai Moldovan wrote:

> > Aren't you relying on the assumption that all ports register all the files they install?
> 
> They really should. If they don't, that's arguably a bug. Exceptions may
> apply.

Let me clarify: do all ports register all files that are somehow related (not necessarily installed; possibly created afterwards, etc). This came up when we discussed using the archive tarballs to reinstall a port, or to recreate those tarballs from the currently installed stuff, and I remember there was good reason that ports can have associated files that are not registered.
I cannot come up with a good example right now, but I expect that there might be build systems (or portfiles) that use such files one way or another.

> I should add another fact to clear up some confusion: files, which are
> not registered by a specific port are *not* affected by trace mode at
> all. They can be accessed as-is. This also holds for symlinks that are
> created by port select and the like.

Which is exactly what I was getting at. If they were inaccessible (because trace mode allows access only to registered files that are sanctioned explicitly) you'd get an error, and the missing dependency becomes apparent. If a port can access them (because tracemode block access only to registered files that are not sanctioned explicitly) trace mode doesn't help.
Granted, a marginal use case that got blown out of proportions because of an apparent communication glitch :)

> there (not provided Apple, not provided by MacPorts) in /usr/local, this
> directory tree is completely shadowed.

Good. I still keep stumbling over stuff in there on my own system.

R.


More information about the macports-dev mailing list