On 08/23/2011 09:16 PM, Joachim Breitner wrote: > Hi Matthias, > > Am Dienstag, den 23.08.2011, 20:58 +0200 schrieb Matthias Klose: >> as shown in bug #639015, haskell packages make up to 80% of the libffi >> rdepends, >> which looks a bit insane. At some time I would like to get the libffi >> version >> in experimental to unstable, maybe it's worth either waiting until this >> issue is >> fixed, or coordinate the libffi soname bump or the haskell abi transition >> (there >> seem to be plenty of it ;) > > ok, that explains your motivation :-) > > 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? > 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. Matthias -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
