Bug 233621 - textproc/enchant - shared lib symlink fails to install
Summary: textproc/enchant - shared lib symlink fails to install
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-gnome mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-29 00:34 UTC by dave
Modified: 2018-12-12 20:22 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (gnome)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dave 2018-11-29 00:34:29 UTC
FreeBSD 11.2-STABLE and ports branch 2018Q4. So after a poudriere build and a subsequent pkg upgrade, my libraries look like this:

 # ls -l /usr/local/lib/libenchant*
 -rw-r--r--  1 root  wheel  60142 Nov 20 06:26 /usr/local/lib/libenchant-2.a
 lrwxr-xr-x  1 root  wheel     21 Nov 20 06:26 /usr/local/lib/libenchant-2.so@ -> libenchant-2.so.2.2.3
 lrwxr-xr-x  1 root  wheel     21 Nov 20 06:26 /usr/local/lib/libenchant-2.so.2@ -> libenchant-2.so.2.2.3
 -rwxr-xr-x  1 root  wheel  40960 Nov 20 06:26 /usr/local/lib/libenchant-2.so.2.2.3*
 -rw-r--r--  1 root  wheel  63990 Nov 20 03:44 /usr/local/lib/libenchant.a
 -rwxr-xr-x  1 root  wheel  44424 Nov 20 03:44 /usr/local/lib/libenchant.so.1.6.0*

Notice there's no libenchant.so.1 symlink. This breaks claws-mail, and probably anything else attempting to use v1 of the library. The quick fix is:

 # cd /usr/local/lib
 # ln -s libenchant.so.1.6.0 libenchant.so.1

Now I do note that I have both enchant and enchant2 installed...
  
 # pkg info -r enchant2
 enchant2-2.2.3_1:
	webkit2-gtk3-2.20.5
 # pkg info -r enchant
 enchant-1.6.0_8:
	webkit-gtk2-2.4.11_17
	kdelibs-kde4-4.14.38_6
	claws-mail-3.16.0_1
	libsexy-0.1.11_10
	gtkspell-2.0.16_6

so that may be a consideration. I have build logs if you need those.
Comment 1 John Hein 2018-11-29 09:52:15 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
Comment 2 dave 2018-12-03 00:08:17 UTC
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
Comment 3 John Hein 2018-12-04 00:12:08 UTC
(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.
Comment 4 dave 2018-12-10 02:07:35 UTC
(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.
Comment 5 John Hein 2018-12-11 14:28:28 UTC
(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)?
Comment 6 dave 2018-12-12 20:22:09 UTC
(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?