[Pkg-haskell-maintainers] libffi soname change upcoming

[Joachim Breitner]

Hi,

Am Mittwoch, den 24.08.2011, 12:44 +0200 schrieb Matthias Klose:
> > The question that has to be answered first is: Assume the libraries do
> > not depend on libffi themselves, and only ghc does. Now you update
> > libffi and ghc gets rebuilds, what will happen:
> > 
> >  A) The haskell ABIs stay the same, the existing library packages can
> > still be used. Great.
> > 
> >  B) The haskell ABIs change. We’ll have to binNMU all Haskell libraries,
> > but oh well, not bad thanks to BD-Uninstallable-support in wanna-build
> > and autosigning.
> > 
> >  C) The haskell ABIs do not change, but the old library builds are
> > broken nevertheless. Big mess. Hard to recover from, because builds are
> > not ordered automatically any more. Needs lots of NMUes and Dep-Waits.
> 
> sorry, I don't get the `C' case. why should these be broken by a libffi or
> libgmp change?

Maybe it’s an unrealistic example, but I could imagine that ghc some
data type (size) defined by libffi is used when generating code for a
haskell library under the assumption that it has the same structure/size
in the run time system and/or other used haskell libraries.

But instead of making blind guesses, maybe GHC upstream can enlighten
us: Is it safe to build ghc and a Haskell library, then upgrade libffi
to a new version (with soname bump), rebuild ghc, but use the previous
library build?

> > Removing the libffi dependencies from the haskell libraries makes C
> > possible and only helps with A. So until someone investigates this, I’d
> > rather err on the safe side, leave the dependencies in, and fix the
> > issue by rebuilding all haskell libraries when you upload the new ffi
> > soname to unstable.
> 
> well, with binNMU orgies like this you'll pull in any new or tightened
> dependencies for shared libraries. Not depending on these unused libraries
> does avoid this.

True. I agree that it would be nice and worthwhile to remove the libffi
dependency from the libraries, but only if it is actually safe and
scenario C is guaranteed not to happen.

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata at debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata at joachim-breitner.de | http://people.debian.org/~nomeata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20110824/b7b0130e/attachment.pgp>