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
nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part