Summary: | textproc/enchant - shared lib symlink fails to install | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | Dave Hayes <dave> |
Component: | Individual Port(s) | Assignee: | Walter Schwarzenfeld <w.schwarzenfeld> |
Status: | Closed Overcome By Events | ||
Severity: | Affects Some People | CC: | dave, jcfyecrayz, w.schwarzenfeld |
Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(gnome) |
Version: | Latest | ||
Hardware: | Any | ||
OS: | Any |
Description
Dave Hayes
2018-11-29 00:34:29 UTC
Remove your manual quick fix link (sudo rm /usr/local/lib/libenchant.so.1), and run pkg check: sudo pkg check -s -v libenchant Well this: # pkg check -s -v libenchant produces: pkg: No packages matching: libenchant So I assume you meant this: # pkg check -s -v enchant [1/1] Checking enchant-1.6.0_8: checksums...enchant-1.6.0_8: missing file /usr/local/include/enchant/enchant++.h enchant-1.6.0_8: missing file /usr/local/include/enchant/enchant-provider.h enchant-1.6.0_8: missing file /usr/local/include/enchant/enchant.h enchant-1.6.0_8: missing file /usr/local/lib/libenchant.so enchant-1.6.0_8: missing file /usr/local/lib/libenchant.so.1 enchant-1.6.0_8: missing file /usr/local/libdata/pkgconfig/enchant.pc enchant-1.6.0_8: missing file /usr/local/man/man1/enchant.1.gz done (In reply to dave from comment #2) Yes, quite so (pkg check -s -v enchant). So based on that output you provided, it seems the package expected the missing files. So either: (1) the files were not in the package you installed from (2) the files got removed somehow after the package was installed (3) the package install was interrupted (disk full issue perhaps??) Generally, pkg(8) won't build a package incorrectly, so it's probably (2) or (3). If so, you have to figure out how that happened. You could look at modification times of directories to see when a file may have been deleted (if it hasn't been touched since then). Or other sleuthing (think about changes that have occurred since the package was installed - note that the date for a pkg install will usually be logged in /var/log/messages, also 'pkg info enchant'). Do you still have the package from your poudriere build? You can inspect it with 'pkg info -R'. You could reinstall from that package. That would probably fix your problem but won't necessarily tell you when / why things went bad after that. If the package is correct (which it seems to be since it is complaining about the missing files), then build logs won't help, as the removal of the files probably occurred after the build / install. (In reply to John Hein from comment #3) Ordinarily, I would just reinstall this package. The machine in question has easily had N major "pkg upgrade" done (N > 1 and probably somewhere around 8) to it. The entire system is complex enough that I'm pretty sure edge cases abound that ports maintainers might not have thought about and I can always reset things. However, there is at least one other person with the same problem. :) So I don't mind sleuthing about some just to make sure this is only my issue and not an actual bug. There's definitely something weird going on because as part of 'pkg upgrade': # grep enchant /var/log/messages Nov 28 14:50:12 myhost pkg: enchant-1.6.0_8 installed Nov 28 14:50:33 myhost pkg: enchant-1.6.0_7 deinstalled Nov 28 15:08:53 myhost pkg: enchant2-2.2.3_1 installed Note the order of operations there. Further, I see this in pkg info -R: files { ... /usr/local/lib/libenchant.so.1.6.0 = "1$9977c2fc2550207d3c88f7eb7d0403acb4a235b0cc5a7a7d640b8c3b4d5e297e"; ... } I presume the 1$ means "MD5 checksum". Proceeding on this presumption, none of those entries I checked match the actual MD5 checksums of the files: md5 /usr/local/lib/libenchant.so.1.6.0 MD5 (/usr/local/lib/libenchant.so.1.6.0) = a44295a753873da58a52418355d57493 So I'm fairly clueless as to what actually happened here. I did check the enchant2 package to see if libenchant.so.1.6.0 was inside, but it's not. (In reply to dave from comment #4) That's a sha256 hash, not md5. I agree the install then deinstall ordering looks fishy. Did you save the output of 'pkg upgrade'? Do you have before / after conditions (e.g., which pkgs were installed before the upgrade vs. after)? (In reply to John Hein from comment #5) Sadly, I did not save the output of pkg upgrade nor do I have before/after conditions. I have one other machine to upgrade in the near future that contains this library and is in the same pre-upgrade position as the bugged machine. It would seem the best idea for me is to wrap pkg upgrade in a script and capture the above as an output log. So I will do that unless there's a better idea. Is there anything else I can do on the currently bugged machine that can help? (In reply to dave from comment #0) -rw-r--r-- 1 root wheel 61334 31 Juli 02:42 /usr/local/lib/libenchant-2.a lrwxr-xr-x 1 root wheel 21 31 Juli 02:42 /usr/local/lib/libenchant-2.so -> libenchant-2.so.2.2.3 lrwxr-xr-x 1 root wheel 21 31 Juli 02:42 /usr/local/lib/libenchant-2.so.2 -> libenchant-2.so.2.2.3 -rwxr-xr-x 1 root wheel 41376 31 Juli 02:42 /usr/local/lib/libenchant-2.so.2.2.3 -rw-r--r-- 1 root wheel 63990 19 Jan. 2019 /usr/local/lib/libenchant.a lrwxr-xr-x 1 root wheel 19 19 Jan. 2019 /usr/local/lib/libenchant.so -> libenchant.so.1.6.0 lrwxr-xr-x 1 root wheel 19 19 Jan. 2019 /usr/local/lib/libenchant.so.1 -> libenchant.so.1.6.0 -rwxr-xr-x 1 root wheel 44432 19 Jan. 2019 /usr/local/lib/libenchant.so.1.6.0 Seems solved. So I close here. If there still problems, please, reopen. |