port upgrade outdated order

[Chris Jones]

Hi,

On 04/03/15 17:29, René J.V. Bertin wrote:
> 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.

If you can come up with an example, I would again personally classify 
that as a bug in the port that should be fixed. *anything* a port 
installs should be installed during the destroot phase, and thus be 
properly registered. If there are ports that side-step this, then those 
ports are at fault.

>
>> 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 :)
>

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) ?

Anyway, all the more reason that if a port 'installs' files outside the 
normal MP system and thus they are not registered, that should be 
regarded as a bug in that port.

Chris

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