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