Understanding ghc-pkg dependencies when not using cabal
tim at gfxmonk.net
Sat Jun 2 09:51:29 CEST 2012
On Sat, Jun 2, 2012 at 5:38 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> as I’m involved with the Debian packaging I can probably answer a few of
> your questions.
> Am Samstag, den 02.06.2012, 00:01 +1000 schrieb Tim Cuthbertson:
>> For an example, lets use ansi-terminal  (and assume we're building
>> it on a unix host)
>> ansi-terminal depends on `base` and `unix` packages. Do these need to
>> be present in source form, or just in "compiled package" form? I'm
>> assuming the latter.
>> (by "compiled package", I mean the stuff that ends up in e.g
> Correct. See
> for what Debian packages contain; that is sufficient to build libraries
> depending on this one. (We have separate -prof and -doc packages,
>> When I built ansi-terminal, the package.conf I got out of `cabal
>> register` had the following field:
>> depends: base-184.108.40.206-6db966b4cf8c1a91188e66d354ba065e
>> So presumably this is the exact version that was used for compilation.
>> Obviously the first part is the version, but what is the second part?
>> Is it the abi-hash of the library that was used at compile time?
> It is a hash across everything that is being exposed by the library, so
>> If I want to use ansi-terminal in a program that I'm compiling, how
>> strict are these dependencies? Will a `unix` package of a different
>> version and the same abi-hash be acceptable? Does it need to be
>> strictly _newer_ than 220.127.116.11 (and still have the same abi-hash)? Or
>> is this an exact dependency? If I distribute the `unix` library in
>> compiled form, how likely is it that a given compiled version of
>> `unix` will satisfy the requirement?
> They are very strict, i.e. both version _and_ hash have to match.
>> If I have compiled two libraries that both depend on `unix`, but they
>> ended up referencing a different abi-hash of `unix` (maybe I compiled
>> them on a different computer, or on slightly different versions of the
>> source), what happens when I try to compile an application that
>> depends on these two libraries? I presume it couldn't work,
> it can work, at least if the unix libraries they have _different_
> versions and the two libraries do not try to interact using types or
> type classes from unix. We have had this situation with parsec-2 and
> parsec-3 for a while in Debian and worked ok, but should probably be
>> even if I
>> had registered both versions of `unix` simultaneously (is this even
>> possible to do?).
> AFAIK it is not yet possible, but it is planned to make that possible.
>> Under what circumstances will the same package source code (e.g
>> "unix-18.104.22.168") have two different abi-hashes? From , it sounds
>> like only major GHC version changes should affect it. Is the abi-hash
>> consistent on different platforms (assuming the same major GHC version
>> is used)?
> Different GHC versions, different versions of depending libraries, in
> some cases other stuff. E.g. the abi hash of the ghc library itself
> varies depending on the version number of the ghc you compile ghc with.
> So the first build of a new ghc version has a different abi hash than
> the second build (if it is the first built with the new version). This
> causes some problems here on the Debian front. Generally assume ABI
> hashes to be fragile, and be happy if they don’t change.
>> Can the output of `ghc --abi-hash` (with no arguments) be used as a
>> "linkage" restriction? (i.e if I have the exact same source and two
>> versions of ghc with the same abi-hash, will the compiled library
>> necessarily end up with the same abi-hash in both cases?).
> Likely, but I suggest not to rely on it in your packaging processes. Or
> at least prepare to detect if it goes wrong and clean up.
>> If the `unix` package releases a new version that is compatible with
>> ansi-terminal, what would I have to do to get this updated code into
>> my application (that depends on ansi-terminal)?
>> - install new version of `unix`, and recompile my application
>> - as above, but also rebuilding the current version of
>> `ansi-terminal` before I rebuild my application (despite ansi-terminal
>> not actually changing itself)
> The latter.
>> Perhaps the above question could be rephrased as "if a new version of
>> `unix` is source-compatible with the previous, what recompilation (if
>> any) of downstream libraries is / could be required?
> Simple: Rebuild all.
> Ok, not entirely true: It may happen that A depends on B and B on C, an
> upgrading C requires a rebuild of B but the ABI hash of B is not
> affected. In that case you do not have to rebuild A, but there is no way
> of telling in advance.
>> I know that ghc compiles applications statically by default. Given
>> this, I'm a little confused by the lifetime of packages in ghc. Are
>> packages (in the sense of "the stuff that is listed by `ghc-pkg
>> list`") only required at compilation time?
> Yes. Haskell-based programs in Debian do not carry any haskellish
> dependendencies any more, e.g.
> Given the fragility of library dependencies described above, this is a
> good thing for us.
>> If I run a precompiled
>> program that depends on another haskell package which has been
>> compiled as a shared library, does this mean I need the ghc package to
>> be registered, or is it sufficient to just have the compiled .so on my
> I have no experience with shared libraries; in Debian we do not use them
> (yet) for the reason just mentioned.
> Joachim "nomeata" Breitner
> mail at joachim-breitner.de | nomeata at debian.org | GPG: 0x4743206C
> xmpp: nomeata at joachim-breitner.de | http://www.joachim-breitner.de/
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
Thanks very much for your response, that clears up a lot of confusion I had.
In general, it sounds like for zero install, it would be infeasible to
distribute "compiled" libraries given the fragility and specificity of
dependencies - since very frequently libraries that have been compiled
in a different context may end up with different IDs, despite
identical source code. For debian it sounds like this works by doing a
rebuild of all packages when necessary, but that doesn't seem workable
for a system like zero install - both because it is distributed and
because there is no scope for flagging that an implementation needs
recompilation despite the fact that it has not itself changed.
Similarly, it doesn't sound worthwhile pursuing shared libraries if
the dependencies at runtime will be as brittle as compile-time
I've written up my findings on the zero-install list as to how we
might proceed in supporting feeds / packages using ghc better, if
people are interested:
Please correct me if I've misunderstood anything.
More information about the Glasgow-haskell-users