Hi,
On Sun, May 24, 2020 at 04:07:50PM -0700, Greg Steuck wrote:
> I only now realized how obnoxious version keying property of cabal is
> when applied to ports. A full-tree ghc upgrade is OK, I expect to
> touch everything. But updating a single library close to the bottom of
> dependency graph is not fun all.
>
> Say I updated devel/hs-dlist. It's a trivial patch (attached, not
> sufficient as is). Now I try to build e.g. devel/hs-data-default and
> it breaks because its package key has changed which in turn will lead
> to all its transitive dependants getting a revision.
Yes, it's annoying.
> I know why GHC behaves this way, but this property turns minor updates
> into major events.
Should we do an experiment and try to get rid of MODGHC_PACKAGE_KEY?
That would be one sweep over all hs-ports, which I could do on a
weekend.
The risk would be that the old behaviour strikes back, i.e. some
stupid constant somewhere changes and causes symbol name changes
in hs-libraries. For example, in the past, changing the build date
of the ghc bootstrapper was enough to cause symbol name changes in
ghc's libs (IIRC that was the reason why I initially introduced
that MODGHC_PACKAGE_KEY).
Ciao,
Kili
No comments:
Post a Comment