Skip to content
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

xhtml package still clash with that shipped with GHC 7.8.4 #6012

Closed
jraygauthier opened this issue Jan 28, 2015 · 2 comments
Closed

xhtml package still clash with that shipped with GHC 7.8.4 #6012

jraygauthier opened this issue Jan 28, 2015 · 2 comments

Comments

@jraygauthier
Copy link
Member

collision between /nix/store/bdqq3j1bl4s6mm7cr2jmspnz9md63vkb-ghc-7.8.4/lib/ghc-7.8.4/xhtml-3000.2.1/Text/XHtml/Table.hi and
/nix/store/c8p9y30f11d444qfsvl04w45s99m284h-haskell-xhtml-ghc7.8.4-3000.2.1-shared/lib/ghc-7.8.4/xhtml-3000.2.1/Text/XHtml/Table.hi at
/nix/store/9z6d76pz8rr7gci2n3igh5dqi7ac5xqj-builder.pl line 72.

As of 5e7501c building the gitit package.

In a previously sent pull request #5060 which was closed mentioning the problem was on GHC side, I mentioned the same issue and was redirected to https://ghc.haskell.org/trac/ghc/ticket/8919. In a
second reading, I found that it may be nix which it at fault. Indeed, from the last post by @slyfox,
it would seem that

ghc's xhtml is already a private lib

and that

I see a problem in one single case: if you install haskell libs in ghc's private subdir.
I'd strongly suggest against that practice and pick any other random dir out there.

ghc's private directory being lib/ghc-7.8.4/xhtml-3000.2.1 infix, it seem that nix is indeed
installing its haskell packages in ghc's private directory which, it would seem to me
is why we have this problem in the first place.

@slyfox also mentionned that

On gentoo we just install external haskell libs in other location:
/usr/lib64/xhtml-3000.2.1/ghc-7.8.2/libHSxhtml-3000.2.1-ghc7.8.2.so

which would correspond to someting like lib/xhtml-3000.2.1/ghc-7.8.4 infix
for nix.

Shouldn't nix avoid as well installing its haskell packages in ghc's private dir
so as to avoid further problems. It is clear to me from the ghc ticket that
this is to be avoided.

@jraygauthier
Copy link
Member Author

Added the xhtml = null attribute to ghc784Prefs in hakell-defaults.nix allowed the build to
proceed.

@peti
Copy link
Member

peti commented Jan 28, 2015

@jraygauthier, thank you very much for the detailed bug report. I appreciate the effort you've put into clarifying the issue. I have a couple of comments in no particular order:

  • The fact that haskell-defaults.nix is lacking a xhtml = null override is a bug. xhtml is a core library in GHC 7.8.4 just like base is, and it's a mistake to try and build the exact same version as a user and try to make builds use that one instead of the one that comes with the compiler.
  • Generally speaking, the haskellPackages set is slightly unmaintained. I wouldn't say it's dead, but it's smelling funny, IMHO, and you should probably switch to haskellngPackages instead, which doesn't have this problem.
  • I have no idea what @slyfox means by calling xhtml a "private library". According to ghc-pkg describe xhtml, it's by no means private: it's a core library everyone is free to use. As such, he's doing his users no favor by inventing directory trickery that allows them to install another version of xhtml, because they'll end up with broken binaries if they ever pick a combination of packages that links both the core and non-core variant of xhtml at the same time.
  • GHC's lib directory is not a "private" directory. No collision occur when you install different versions of the same library into that place. Collisions occur only if you try to install the exact same library twice -- and this is a good thing, because an installation that provides two competing copies of the same library is inherently broken.

I hope this helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants