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.