Bug 221372 - lang/ghc/bsd.cabal.mk: pkg: DEINSTALL script failed
Summary: lang/ghc/bsd.cabal.mk: pkg: DEINSTALL script failed
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-haskell mailing list
Depends on:
Reported: 2017-08-09 16:40 UTC by Mathieu Arnold
Modified: 2019-05-28 15:56 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Arnold freebsd_committer 2017-08-09 16:40:24 UTC
Today, upgrading my hs-* packages, I got:

[7/15] Upgrading hs-syb from 0.5.1 to 0.7...
[7/15] Extracting hs-syb-0.7: 100%
ghc-pkg: cannot find package syb-0.5.1
/bin/sh: ./gen_contents_index: not found
pkg: DEINSTALL script failed
[8/15] Upgrading hs-regex-base from 0.93.2_14 to 0.93.2_15...
[8/15] Extracting hs-regex-base-0.93.2_15: 100%
ghc-pkg: cannot find package regex-base-0.93.2
/bin/sh: ./gen_contents_index: not found
pkg: DEINSTALL script failed
[9/15] Upgrading hs-parsec from 3.1.9 to 3.1.11...
[9/15] Extracting hs-parsec-3.1.11: 100%
ghc-pkg: cannot find package parsec-3.1.9
/bin/sh: ./gen_contents_index: not found
pkg: DEINSTALL script failed
Comment 1 Gabor Pali freebsd_committer 2017-08-09 16:53:53 UTC
What were the exact sequence of commands that you used?  Did the upgrade succeed eventually?

As far as I remember, either of those messages should not be fatal: the one with saying

ghc-pkg: cannot find package syb-0.5.1

means the since you are switching between GHC versions, the ghc-pkg tool could not find the package in its database as it wiped clear in the process.  The other with saying

./gen_contents_index: not found

means that it could not rebuild the documentation index for the libraries, the script is now missing as it was removed together of the old instance of GHC.

That is why I recommended in the UPDATING entry to first delete all hs- packages, upgrade lang/ghc, and then reinstall everything you had.
Comment 2 Mathieu Arnold freebsd_committer 2017-08-09 19:52:18 UTC
I ran pkg upgrade.

The upgrade may have succeded, I don't really know, the only thing I use is shellchecker, and it still works.
Comment 3 Gabor Pali freebsd_committer 2017-08-09 20:39:00 UTC
Well, pkg upgrade is not the preferred way.  The way of things are laid out for the package manager of GHC is not compatible with the current behavior of pkg.  That is a known problem from the previous major updates as well.
Comment 4 Mathieu Arnold freebsd_committer 2017-08-09 21:55:54 UTC
pkg upgrade is the only way.
Even if you run use other tools than poudriere, the framework still ends up doing a pkg delete and a pkg add. Which is exactly the same.
Comment 5 Gabor Pali freebsd_committer 2017-08-10 08:59:36 UTC
If I recall correctly, the problem with pkg-upgrade is the order of pkg-adds and pkg-deletes.

In the suggested way, one should first remove all the dependents, that is, the hs- packages, then lang/ghc.  So, on each deinstall they can safely run the gen_contents_index script and ghc-pkg can safely delete them from the package database.  On the contrary, on pkg upgrade, first lang/ghc is replaced, then the hs- ports.  Then, since the path of gen_contents_index has changed and the package database of GHC is wiped, one will get the errors you reported.

For example, the previous version of the hs-syb package was installed for GHC 7.10.2.  So its DEINSTALL script has the following command:

cd /usr/local/share/doc/ghc-7.10.2/html/libraries &&  /bin/rm -f doc-index*.html && ./gen_contents_index

Because lang/ghc was replaced with version 8.0.2 before running that, the gen_contents_index script cannot be found any more, so it fails.

One might say that okay, let us hack this problem around the make it independent of the actual version of GHC.  But what if the way of handling the document index has changed between the versions of GHC?  We cannot expect a GHC package installed with version X to properly clean up itself with version Y.
Comment 6 Mathieu Arnold freebsd_committer 2017-08-10 09:34:14 UTC
Mmm, but, whatever tool you use to maintain your installed packages, the upgrade always goes the same way, which is upgrade each port/package, one at a time, up the dependency tree.

It has to work, the package manager we use is pkg, and it works fine with many third party systems, like Perl's, Python's... I'm sure something can be done here too.
Comment 7 Gabor Pali freebsd_committer 2017-08-10 09:47:14 UTC
I admit that the GHC package management is not the most sophisticated one, and I accept that things should just work with pkg-upgrade.  But hey, we still have an UPDATING file... :-P

For what it is worth, I believe that the problem could be just solved by making those commands optional.  Since, as I have demonstrated above, updating the doc-index file and deleting the package from the database are tied to a specific version of GHC -- if the version that was used for adding the package is not present any more, just skip them.
Comment 8 Mathieu Arnold freebsd_committer 2017-08-10 12:59:36 UTC
Note that the only thing that is left over in the doc directory after the upgrade is:

find /usr/local/share/doc/ghc-7.10.2/ -exec ls -ldFG {} +
drwxr-xr-x  3 root  wheel   3  1 mars   2016 /usr/local/share/doc/ghc-7.10.2//
drwxr-xr-x  3 root  wheel   3  9 août  18:11 /usr/local/share/doc/ghc-7.10.2/html/
drwxr-xr-x  2 root  wheel   3  9 août  18:12 /usr/local/share/doc/ghc-7.10.2/html/libraries/
lrwxr-xr-x  1 root  wheel  59 22 mars   2016 /usr/local/share/doc/ghc-7.10.2/html/libraries/ShellCheck-0.3.8@ -> /usr/local/share/doc/cabal/ghc-7.10.2/ShellCheck-0.3.8/html

But in the lib, there are more stuff:

# find /usr/local/lib/ghc-7.10.2/

As in, I think, the packages registration.
Comment 9 Gabor Pali freebsd_committer 2017-08-10 13:29:43 UTC
In "/usr/local/lib/ghc-7.10.2/package.conf.d" what you see are the leftovers from the unsuccessful packages unregistrations.  The ghc-pkg command could not find those files as it was searching under the package configuration database of GHC 8.0.2, so it could not delete them.  Note that it would not be enough just to teach ghc-pkg where to find those files -- the way of ghc-pkg handling package registrations may change over versions, including the name of the directory or the actual format of the contained files.  And on deinstall, since lang/ghc has been already replaced earlier, the new version ghc-pkg will be invoked.  (Yes, no backward compatibility may be expected.)

A potential solution for that would be to nuke that directory entirely on the deinstallation of lang/ghc.

As for "/usr/local/share/doc/ghc-7.10.2/html", lang/ghc could not get rid of the directory on deinstall because the packages are still storing their HTML documentation there.

I am currently out of ideas on what to do with that latter one.
Comment 10 Gabor Pali freebsd_committer 2017-08-10 13:32:37 UTC
Is not there way to tell pkg to respect this strict ordering between the package dependencies, or do something similar I described in the UPDATING file on pkg-upgrade?
Comment 11 Walter Schwarzenfeld freebsd_triage 2018-01-19 19:44:15 UTC
Is this still relevant?
Comment 12 Gleb Popov freebsd_committer 2019-05-28 15:56:14 UTC
No more script magic in Haskell packages.