http://bugzilla.opensuse.org/show_bug.cgi?id=998972 Bug ID: 998972 Summary: ghc: haskell ABI is not stable through rebuilds Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://build.opensuse.org/project/show/openSUSE:Maint enance:5585 OS: Other Status: CONFIRMED Severity: Major Priority: P5 - None Component: Development Assignee: mimi.vx@gmail.com Reporter: astieger@suse.com QA Contact: qa-bugs@suse.de CC: adrian@suse.com, astieger@suse.com, bbrunner@suse.com, lnussel@suse.com, mimi.vx@gmail.com, psimons@suse.com Found By: --- Blocker: --- I would like to track the issue with the Haskell compiler ghc, and the issue it creates specifically when maintaining these packages in a distribution like openSUSE. As discussed in https://build.opensuse.org/project/show/openSUSE:Maintenance:5585 Previously: bug 931321 Let me just quote what Peter wrote. Haskell library packages have a unique identifier -- a hash that's computed over all functions and data types the library contains. When a library is linked into another library (or an application), the linker records that hash as part of the dependency information. This information guarantees that the library provided for the build cannot be changed at a later point; if you want to upgrade any component of the dependency tree, then you have to re-link all (transitive) dependents. Now, this is a fine mechanism to guarantee reliable builds for a language that relies heavily on cross-module in-lining, but unfortunately the hashes generated by the compiler are unstable (https://ghc.haskell.org/trac/ghc/ticket/4012). This means that two builds of the same source code may end up being assigned two different IDs. Consequently, there is no stable binary interface in GHC-compiled code. If any Haskell package is rebuilt, then all its (transitive) dependents must be re-built, too. An attempt to run an application that had any one of its dependencies re-compiled will fail with some non-zero probability (https://github.com/peti/ghc-library-id-bug). Since GHC provides some base libraries itself, a re-build of GHC must trigger a complete re-build of all Haskell packages to ensure that none of those packages get into a broken state. The hashes you see in the dependency information visualize that information. I'm not sure how that works, exactly, but I believe the intention of that addition was to avoid unnecessary re-builds, i.e. if a re-compiled GHC does not change any of its library IDs, then all dependencies still match and no re-build are necessary. If any of the IDs do change, however, then RPM is able to detect that a given package is broken. Whether that triggers re-builds in OBS or not I'm not sure; but it seemed to me like those IDs did fix the missing re-builds for us when they were added into the dependency information. ---- Just to let you know that in openSUSE:Maintenance:5585, the solution was to stop all builds, have ghc build completely, and then allow all depending packages to build. It was observed that a build of ghc alone would not trigger builds for the complete project so that all dependencies are resolvables. So now that I understand the problem better, we could discuss the following: * Making Haskell builds deterministic * Making obs trigger the transient build correctly * Find a way to make Haskell suitable (more) for maintenance without requiring full rebuilds. Given Peter's explanation, this may not actually be possible. -- You are receiving this mail because: You are on the CC list for the bug.