[Hackage] #738: Recompiling the same library version can change its ABI, causing breakage (even of Cabal)

[Hackage]

#738: Recompiling the same library version can change its ABI, causing breakage
(even of Cabal)
----------------------------+-----------------------------------------------
  Reporter:  Blaisorblade   |        Owner:         
      Type:  defect         |       Status:  new    
  Priority:  normal         |    Milestone:         
 Component:  Cabal library  |      Version:  1.8.0.4
  Severity:  major          |     Keywords:         
Difficulty:  unknown        |   Ghcversion:  6.10.4 
  Platform:                 |  
----------------------------+-----------------------------------------------
 On my system, cabal recompiled a package on which Cabal itself depended,
 breaking the linking of Setup.hs when trying to update new packages.

 My problem was partially due to an upgrade of a "core package" (on which
 cabal depends): install of core packages should be refused, for the same
 reason that "cabal upgrade" is disabled. But that's a side issue, probably
 known.

 Recompiling a non-core package could break silently another non-core
 package, in the same way. The root problem, IMHO, stems from handling of
 dependencies. Compiler-generated identifiers are exported, due to cross-
 module linking, and they depend from used modules and options about
 compilation (especially optimization).

 It thus seems that the ABI of a module is a (pure) function of the
 versions of all its (transitive) dependencies, and their compilation
 options - in particular, the optimization options and the used compiler
 version. Surely, the ABI does not depend just on the package version.

 More formally, my conjecture is:
 - let us represent "package a depends on b" as "a =>> b", where a, b are
 package names tagged with a version
 - let =>>* be the transitive-reflexive closure of =>>
 we need to compute:
 DEPS(p) = {q | p =>>* q }
 TAGGED_DEPS(p) = { (q, compilation_opts(q)) | q \in DEPS(p) }
 where compilation_opts(q) are the compilation options used to compile
 package q.

 Then, the ABI of package p is a pure function of TAGGED_DEPS(p), not just
 of p. My experience proves at least that the ABI does not depend just on
 p.
 Possibly, a package ABI depends on the build ID, if internally generated
 identifiers are random, but it does not look like that on my system (they
 are sequentially generated).

 Finally, there should be a way to automatically recompile dependent
 packages, as in Gentoo's revdep-rebuild. In my case, I wasn't prevented by
 ghc-pkg from removing a package on which other packages depended, while it
 does do some dependency tracking.

 Further info is being discussed on Haskell-cafe in this thread:
 http://groups.google.com/group/haskell-
 cafe/browse_thread/thread/838f2c098941bac9

 Software versions:
 cabal-install version 0.8.2
 using version 1.8.0.6 of the Cabal library (installed through Hackage, not
 available in this bug report form under "version").
 GHC 6.10.4

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/738>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects