Conflict with global database when copying precompiled package

[zudov]

Here is an issue which I've been experiencing for quite a long time (since copying precompiled packages feature was merged):

transformers-compat-0.4.0.4 is in global database and in lts-3.8 snapshot database:

+zudov@x200 /tmp/empty-project $ stack exec ghc-pkg list transformers-compat --resolver lts-3.8
/usr/lib64/ghc-7.10.2/package.conf.d:
    transformers-compat-0.4.0.4

/home/zudov/.stack/snapshots/x86_64-linux/lts-3.8/7.10.2/pkgdb:
    transformers-compat-0.4.0.4

/tmp/empty-project/.stack-work/install/x86_64-linux/lts-3.8/7.10.2/pkgdb:
    (no packages)

But it's not in nightly-2015-10-08 snapshot database:

+zudov@x200 /tmp/empty-project $ stack exec ghc-pkg list transformers-compat --resolver nightly-2015-10-08
/usr/lib64/ghc-7.10.2/package.conf.d:
    transformers-compat-0.4.0.4

/home/zudov/.stack/snapshots/x86_64-linux/nightly-2015-10-08/7.10.2/pkgdb:
    (no packages)
/tmp/empty-project/.stack-work/install/x86_64-linux/nightly-2015-10-08/7.10.2/pkgdb:
    (no packages)

Trying to install it into nightly-2015-10-08 snapshot database would try to copy it from lts-3.8
and would fail because of the presence of that package in the global database:

+zudov@x200 /tmp/empty-project $ stack build transformers-compat --resolver nightly-2015-10-08
transformers-compat-0.4.0.4: copying precompiled package
Running /usr/bin/ghc-pkg register --no-user-package-db --package-db=/home/zudov/.stack/snapshots/x86_64-linux/nightly-2015-10-08/7.10.2/pkgdb/ --forc
e /home/zudov/.stack/snapshots/x86_64-linux/lts-3.2/7.10.2/pkgdb/transformers-compat-0.4.0.4-3ca5cbcec233c17da785d5f27705643c.conf exited with ExitFa
ilure 1
Reading package info from "/home/zudov/.stack/snapshots/x86_64-linux/lts-3.2/7.10.2/pkgdb/transformers-compat-0.4.0.4-3ca5cbcec233c17da785d5f27705643
c.conf" ... done.

transformers-compat-0.4.0.4: Warning: haddock-interfaces: /home/zudov/.stack/snapshots/x86_64-linux/lts-3.2/7.10.2/doc/transformers-compat-0.4.0.4/tr
ansformers-compat.haddock doesn't exist or isn't a file
transformers-compat-0.4.0.4: package(s) with this id already exist: transformers-compat-0.4.0.4

An output of the last command run with --verbose

It get it quite often with different packages and snapshots. If the package is in a global database the copying would fail.

So far I've been solving it by just removing the offending package from some database. A command line option which tells --do-not-perform-binary-copying would be very helpful.

[snoyberg]

There are a few very strange things going on:

1. Why is transformers-compat in the global database? I'd strongly advise against doing that.
2. Why does Stack think that it needs transformers-compat, if it's already in the global package database?

It sounds to me like there's something broken with your global copy of transformers-compat (strengthened by the error message about the .haddock file), and that Stack is correctly trying to rebuild it. We can tell ghc-pkg to register the package even if it will conflict with an already registered one, but I'd look into first if there's something wrong with your global database.

[snoyberg]

Turns out there's a limitation in ghc-pkg that can be worked around with environment variables. Stack should now work for your use case, though I'd still recommend looking into why you have it in the global database, and if it's broken.

Can you try things out with master (stack upgrade --git)?

[qnikst]

(Maybe a bit unrelated).
Seems that @zudov uses Gentoo where system-wide libraries are installed by package manager in global-db, and package manager checks consistency of the database and notifies and fixes problems if they exists.
However if it this layout is not fully compatible with stack, it's possible to pass options to stack, so it will use package db with bundled libraries only, by passing "-no-global-package-db -package-db=$(ghc --print-libdir)/package.conf.d.initial" --ghc-pkg-options="--global-package-db=$(ghc --print-libdir)/package.conf.d.initial to ghc-options when snapshot is build.

[zudov]

Great. 6b8fd22 fixed the problem. Thanks, @snoyberg.

transformers-compat is just one of the packages with which I experienced that problem, and it doesn't appear to be broken. It's strange that stack installs it into the snapshot databases when it's available globally, I might try to investigate it in the future.

I know that my life would be much easier if I just didn't keep anything non-core in the global database (and in fact that is how I use stack on my main machine), but I think that catching the bugs related to global database wouldn't hurt especially with the current state of things when people often use stack simultaneously with cabal-install and distribution-specific package-managers.

[snoyberg]

Agreed on the "good to catch" bugs front :). Unfortunately Haskell Platform
still makes life miserable sometimes.

On Mon, Oct 12, 2015 at 11:49 AM, Konstantin Zudov <notifications@github.com

wrote:

Great. 6b8fd22
6b8fd22
fixed the problem. Thanks, @snoyberg https://github.com/snoyberg.

transformers-compat is just one of the packages with which I experienced
that problem, it didn't appear to be broken. It's strange that stack
installs it into the snapshot databases when it's available globally, I
might try to investigate it in the future.

I know that my life would be much easier if I just didn't keep anything
non-core in the global database (and in fact that is how I use it on my
main machine), but I think that catching the bugs related to global
database wouldn't hurt especially with the current state of things when
people often use stack simultaneously with cabal-install and
distribution-specific package-managers.

—
Reply to this email directly or view it on GitHub
#1146 (comment)
.