reasons for `port provides` not working?

[René J.V. Bertin]

On Monday October 10 2016 15:30:57 Clemens Lang wrote:

Hi,

> 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.

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

> 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.

Does `port contents` return the result of the reverse lookup? This feature works, and could be used to create a very slow version of `port provides`.

What kind of sqlite expression (evaluated directly in/on the registry db) would normally return the expected information? Is there a ditto command that returns all full paths matching just a filename?

R