[GHC] #8919: Why is xhtml library installed but not exported to users?

[GHC]

#8919: Why is xhtml library installed but not exported to users?
-------------------------------------+------------------------------------
        Reporter:  simons            |            Owner:
            Type:  bug               |           Status:  patch
        Priority:  normal            |        Milestone:  7.8.3
       Component:  Build System      |          Version:  7.8.2
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  Other             |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by slyfox):

 Replying to [comment:17 errge]:
 > I've been asked to briefly summarize the issue, since simons didn't
 write too much about it in the ticket itself.
 >
 > GHC 7.8 uses the xhtml, terminfo and haskeline packages internally.
 Because of the dynamic ghci transition, the related .so files have to be
 shipped with the build.  By not shipping the devel files (not making the
 cabal packages visible), we force the distribution vendors to package up
 these libraries separately and make them available in their repos.
 Nothing wrong with that of course (they do this for all the other
 important libraries, like lens and pipes too).  The problem is that they
 can't ship the .so files in the respective packages, because it's usually
 not allowed for packages to overwrite each other's files in an adhoc
 manner.  So when they build e.g. the xhtml deb or rpm package, they have
 to make sure that if the resulting .so files have the same name as the ghc
 shipped ones, then they don't include it in the package.  These kind of
 workarounds seem extremely kludgy and fragile to me.  This
 naming/overwrite issue causes some headaches for NixOS too, just in a
 slightly different setting.
 >
 > I see two solutions going forward.
 >
 > As nomeata said in comment 16, we can simply ship our .so files in a
 private directory and make our dynamic programs search there (via RPATH or
 some other trick).
 >
 > Or we can simply ship these packages with GHC as we ship base, time and
 so many others.  juhpetersen posted a patch for that in comment 14.
 >
 > Alternatively, we can ignore it and just force people to go with the
 workarounds.  I'd prefer not doing that.  There were also some discussion
 on the mailing list about discontinuing the dynamic change after 7.10 and
 going back to static, which would of course make this go away.

 Thanks for the detailed explanation!

 ghc's xhtml is already a private lib. You can't accidentally use/link
 against it:
 {{{
 /usr/lib64/ghc-7.8.2/xhtml-3000.2.1/libHSxhtml-3000.2.1-ghc7.8.2.so
 }}}
 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
 }}}
 and it's the package registered with cabal/seen with '''ghci -package
 xhtml'''.
 (As you see gentoo ships both .so files, allowing user to rebuild xhtml
 with any random ghc options out there).

 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.

 If we would support multiple ghc versions --prefix might be a
     /usr/$(libdir)/gentoo-ghc-7.8.2

 Anyway, cabal can find them anywhere.

 Or i've misunderstood the clash problem completely?

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8919#comment:22>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler