reasons for `port provides` not working?

[Rainer Müller]

On 2016-10-10 16:49, René J.V. Bertin wrote:
> On Monday October 10 2016 15:30:57 Clemens Lang wrote:
>> IIRC the problem was that your installation mangled paths somehow, either by
>> making /opt/local a symlink or some other uncommon configuration.
> 
> Yes (/opt/local is a symlink), but from what I read on here that is not *that* uncommon and that it's been getting silent support in practice.

What kind of setup is this?
1) /opt/local is the prefix, but the directory was moved and replaced
   with a symlink
2) you installed into a different prefix and then added a symlink at
   /opt/local

> Either way, this shouldn't have any incidence on file-to-port lookups.
> Either:
> - /opt/local/foo/bar is registered as such and a look-up of that path succeeds
> - /opt/local/foo/bar is actually /what/ever/foo/bar, registered as such, and thus a look-up of the resolved path succeeds.
> 
> Neither look-ups work via `port provides` (i.e. via registry::file_registered) but one of them clearly does via [registry::entry owner] (in portimage.tcl::activate_contents). 

Which one does work? What does 'port contents' return?

You could also look into the registry manually to find out which path
was registered. Instructions are here:

https://trac.macports.org/browser/trunk/base/src/cregistry/README.sqlext

For example:
SELECT * FROM files WHERE id = (SELECT id FROM ports WHERE name = 'zlib'
AND state = 'installed');

Note: state 'installed' corresponds to the pseudo-port active, while the
pseudo-port installed would be 'imaged'. Historical reasons.

>> You'll forgive me when I just tell you that problems caused by unsupported
>> modifications made by you locally are not supported by MacPorts. I won't spend
>> any time diagnosing this unless you can show that it's broken in a fresh
>> install.
> 
> Good thing I didn't ask you specifically then... 
> 
> In fact, in absence of proof that my use of a symlinked $prefix explains everything I won't assume that that is the culprit. I'm more inclined to believe that it is the rescue operation I've had to do a year or 2,3 back because an upgrade (2.3.3 -> 2.3.4 IIRC) had not run all required steps. As far as I can remember `port provides` worked perfectly fine in 2.3.3 - and I've always had a symlinked $prefix.

The general rule is that if you run a non-standard installation, you
will have to debug that yourself, because it is complicated to reproduce
your issue for anyone else.

If your last upgrade was not complete, it is usually safe to just re-run
the installation on top of the existing prefix.

Rainer