[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Package abi hash and interface file versions



On 11/07/2011 21:56, Joachim Breitner wrote:
Hi,

in Debian, we use the ghc-pkg ABI hashes to find out what packages we
need to rebuild when. So far, the system has worked great. But now
something unfortunate happened: Yesterday, I upgraded ghc from 7.0.3 to
7.0.4. The ABI hash of base and other libraries changed only on amd64
and kfreebsd-amd64, while they stays unmodified on the other
architectures. That by itself is interesting, but nothing to worry
about, as I assumed that the hashes ensure that packages are rebuild
where required.

But now I see this build log:
https://buildd.debian.org/status/fetch.php?pkg=haskell-mtlparse&ver=0.1.2-1&arch=powerpc&stamp=1310414417
with the relevant line:
Text/ParserCombinators/MTLParse/MTLParseCore.hs:69:1:
     Bad interface file: /usr/lib/haskell-packages/ghc/lib/mtl-2.0.1.0/ghc-7.0.3/Control/Monad/Trans.hi
         mismatched interface file versions (wanted "7004", got "7003")

I don't quite understand - how did 7.0.4 come to be using packages from 7.0.3? The packages go into different directories don't they?

Obviously, the ghc version is encoded into the .hi file and checked
before using it, including the minor patch level. But it seems that this
bit of information is not included in the calculation of the interface
hash! So although the ABI hash did not change between 7.0.3 and 7.0.4,
the package is broken.

I see two solutions for this problem:
  a) (preferred) The ghc version number is not encoded in the .hi file
any more. Instead, a version counter is used that is manually
incremented if there has been an incompatible change to the interface –
after all, not every minor release of ghc changes this format.
>
  b) The interface file version should be included in the hash
generation, so that a package built against the base package of 7.0.3
will clearly state that it does not work with the base package of 7.0.4
and needs to be rebuild.

(Actually, b) should be the case even if a) is done).

Perhaps we should factor the version into the ABI hash. But I'd like to understand more about how things are going wrong for you - I think your use case is one we hadn't considered.

Cheers,
	Simon


Reply to: