Le Monday 8 August 2011 14:04:49, vous avez écrit :
> > you may want to ask for a --with{,out}-libffi flag, so that you can make
> > sure the package is built without libffi support, even if libffi
> > packages are installed in the build environment?
>
> also this seems to be a case for a (even maybe temporary) build-conflicts.
Not really. ffi is just an option for parrot (and for rakudo). parrot is
working with (on i386) or without (on amd64) ffi.
The main problem we have currently is that parrot packages were built
differently on i386 (with libffi) and other archs (without libffi). In all
cases there's no parrot build-dependency on libffi.
I could add libffi-dev to rakudo's build dependencies. It does solve rakudo's
FTBS (verified with cowbuilder). But this solution is not very satisfying:
rakudo does not use directly ffi. Parrot does.
IMHO, there are 2 long-term solutions:
- without ffi: as kibi suggested, this requires a --with{,out}-libffi flag in
parrot's Configure.pl. In the meantime, the binNMU on i386 will achieve the
same result.
- with ffi: parrot needs a build-dep on libfffi-dev and libparrot-dev needs a
dependency on libffi-dev. Then rakudo needs to be re-built for all arches.
Only upstream parrot people know what's best.
Allison, what do you think ?
Once the with-or-without-ffi options are decided, I'll follow-up with rakudo
to have a consistent approach between parrot and rakudo on all arches.
In the short term, the requested binNMU will solve rakudo's FTBS on i386 [1]
and we'll get a consisten feature set on all arches (albeit without ffi).
So could you please run them ?
All the best
[1] https://buildd.debian.org/status/package.php?p=rakudo
Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/
Attachment:
signature.asc
Description: This is a digitally signed message part.