New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conflict with global database when copying precompiled package #1146

Closed
zudov opened this Issue Oct 12, 2015 · 5 comments

Comments

Projects
None yet
4 participants
@zudov
Contributor

zudov commented Oct 12, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Oct 12, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Oct 12, 2015

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)?

@snoyberg snoyberg added this to the P2: Should milestone Oct 12, 2015

@snoyberg snoyberg self-assigned this Oct 12, 2015

snoyberg added a commit that referenced this issue Oct 12, 2015

@qnikst

This comment has been minimized.

Contributor

qnikst commented Oct 12, 2015

(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

This comment has been minimized.

Contributor

zudov commented Oct 12, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Oct 12, 2015

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)
.

dysinger added a commit that referenced this issue Nov 13, 2015

Merge branch 'master' into sig-sign-sdist-and-upload-sign
* master: (59 commits)
  Ignore global database when copying precompiled packages #1146
  Revert an unneeded change to 'runAndLog'
  Remove old GHCJS unpack directory if it exists
  Allow "stack setup ghcjs-0.1.0.20150924_ghc-7.10.2"
  Properly unzip GHCJS on windows (stack setup)
  Consider user-specified package flags in stack solver #1071
  Fix a warning
  Colored build status in filewatch mode
  Add NixOS to 'How to install'.
  Include NixOS information #1118
  Style improvements for Docker compatibility check
  Fix `awaiting pr` label link
  Fix GHC 7.8 build
  Docker: check host's stack compatibility by attempting to run in container and caching the result (#974)
  Fix formatting in `explicit-setup-deps` section
  Provide more information about changed files
  Compile custom Setup.hs instead of interpreting them (fixes #1041)
  Detect when hpc report gives trivial 100% #1009
  Unified coverage report #579
  Recommend extra-dep in yaml_configuration.yml
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment