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