Hi, Am Mittwoch, den 15.05.2013, 11:53 +0200 schrieb Matthias Klose: > Am 15.05.2013 11:29, schrieb Joachim Breitner: > > I’m not sure what there is left to be done: The authors of GHC have > > indicated that it possibly unsafe to remove these dependencies¹, and the > > risk of broken packages at our users installation clearly outweigh the > > nuisance of having a bunch of buildds churn on the packages. > > > > ¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639015#57 > > So you burden Debian with extra work without knowing whether this extra work > is needed or not. You claim to throw broken packages at your users, but you > really don't know. It is not just buildd time, it's man power involved with > such rebuilds, and getting it rebuilt on all architectures it did build > before.
what manpower? If its just scheduling binNMUs, then this is something we have to do regularly for Haskell, and I offered help with that. Otherwise, as far as I know, rebuilds in Debian are, once scheduled, fully automated by now. But I asked more GHC wizards about the issue and at least this one expects no issues: <nomeata> Hi. I need some advice with http://bugs.debian.org/639015. The question is: Do haskell libraries need to be recompiled if the GHC (and hence the RTS) are being built against a new ABI version of libffi? <nomeata> There is some push to remove the dependency on libffi from the indivudial libghc-foo-dev packages to reduce the number of rebuilds, but I’m worried that it might byte us in the end. <dcoutts> mm, interesting question <dcoutts> nomeata: I would expect that the libffi api is not exposed from the rts, so it should not propagate further <dcoutts> but would want to check that <dcoutts> nomeata: rebuilding ghc should give you core packages with all the same ABI hashes as before <nomeata> I was also wondering: Does GHC use the ffi in any way while generating code? I could imagine that it uses libffi to get information about c datatype sizes or ffi internas that are then baked in to the code. <dcoutts> nomeata: I don't see why individual haskell libraries would need to depend on libffi directly <dcoutts> nomeata: not that I'm aware of <dcoutts> I think it's only runtime <nomeata> ok, that would be good. <dcoutts> nomeata: but I recommend you get a second opinion on all this from Igloo <nomeata> I got one from Simon Marlow which is more on the negative side, although I am not sure that I explained the issue well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639015#57 <nomeata> (may I store this conversion in the bug tracker?) <dcoutts> nomeata: I think Simon is assuming that ghc does not get rebuilt <dcoutts> but I think you're saying, rebuild ghc but don't rebuild other libs <dcoutts> effectively, you're expecting that the only thing that changes in the new ghc build is the rts <dcoutts> and all the libs that link to the rts would not change <dcoutts> nomeata: yes you can record this conversation <dcoutts> can/may The next problem is that your patch at http://launchpadlibrarian.net/78632067/haskell-devscripts_0.8.7%2Breally0.8.5_0.8.7%2Breally0.8.5ubuntu1.diff.gz does quite do what it should do: $(nm -u $T_DIR/a.o | grep 'U ffi_' | wc -l) is always going to be 0, independently of whether the package in question does directly use a foreign function whose name starts with ffi_, because a.o is just the compilation of a.hs, which is essentially "main = return ()" and has no relation to the package in question. One could simply and unconditionally remove the dependency on libffi from the substvars file, or more cleanly using the -x parameter to dpkg-shlibdeps. But I guess this will break if haskell bindings to libffi are packages. We do not do that yet, but maybe we (or someone else relying on haskell-devscripts) does, so this seems to be a hack below Debian's standards. The cleanest solution I can think of is to start building dynamic libraries as well, as these can be checked by dpkg-shlibdeps for symbols, so there is no need to build the „test binary“ that pulls in the rts and dpkg-shlibdeps produces exact results. But packaging dynamic haskell would be a pretty large can of new worms and it is not clear when Debian will open it. Conclusion: No good solution in sight, but hacks would be possible, although obviously too late for libffi6. I’d still just rebuild the package and stop worrying – does libffi really get ABI bumps that often? If there is a GHC upgrade near the libffi bump then all haskell packages have to be rebuild anyways. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer [email protected] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [email protected] | http://people.debian.org/~nomeata
signature.asc
Description: This is a digitally signed message part
