Re: how to handle bugs (wishlist) in packages we build depend on
* George Danchev [Sun, 03 Apr 2005 19:43:05 +0300]:
> Hello,
Hi George,
> Here is the situation:
This is pretty technical and specific stuff. If what we can tell you
here doesn't help, perhaps it'd be best that you asked some others
ocaml packages maintainers? Anyway, there we go.
> We have #290338 against ara [1]. Also we believe we have done our packaging
> right, but as you can see from the buildd logs [2] of the latest version, we
> end up with:
> -----log-----
> dpkg-genchanges: arch-specific upload - not including arch-independent
> packages
> dpkg-genchanges: failure: cannot read files list file: No such file or
> directory
> ******************************************************************************
> Build finished at 20050401-0220
> FAILED [dpkg-buildpackage died]
> -----log-----
> on arches with no native ocaml compiler (debian/rules snippet appended [3]).
* * *
> Well, we end up needing dpkg-genchanges and dpkg-buildpackage with support for
> building only architecture-independant parts of the packages (see #109794
> #200454) which I believe will handle our packaging right.
> Now, we end up with #290338 wontfix. But is it a good practice to merge it
> with #109794 #200454 (we believe we depend on)? Will we be informed in that
> case when the last bugs (we depend on) will be resolved so to be able to
> trigger a (re-)build of our package ?
Uhm, why do you believe that solving these dpkg-* bugs is what you
need? Note that when the maintainer uploads, he uploads both arch-indep
packages and binaries for one arch, and then the buildds just upload
binaries for the rest of arches, no more arch-indep uploads. Buildds
are configured, of course, to only build arch-specific packages, and
that is not changing any time soon. Who would use the mentioned
dpkg-buildpackage feature, and how would that improve things?
You certainly want the package to FTBFS on arches with no native ocaml
compiler. In the bug log, Goswin von Brederlow and Thiemo Seufer give
some advice about what to do next. Is there a reason not to do what
Thiemo proposes? (Build-Depend on ocaml-native-compilers instead of
-best-, so that the FTBFS comes by itself, by not having the b-d
satisfied.) You could then drop the list of arches from
debian/control, and the debian/rules snippet. Which is, if you ask me,
a bit of a dirty hack.
But as I said before, you're probably better checking all this with
maintainers of other ocaml packages, which surely have to solve issues
similar to yours.
* * *
Cheers (and full-quoting because I CC'ed the bug report),
> [1] http://ara.alioth.debian.org/
> [2] http://buildd.debian.org/build.php?arch=&pkg=ara
> [3]
> # Build architecture independant packages using the common target.
> binary-indep: build install-indep
> $(MAKE) -f debian/rules DH_OPTIONS=-i binary-common
> # Build architecture dependant packages using the common target.
> binary-arch: build install-arch
> # The arch-dependent packages are only available on archs supported by
> ocamlopt
> -@if [ -x /usr/bin/ocamlopt ] ; then \
> $(MAKE) -f debian/rules DH_OPTIONS=-s binary-common ; \
> else \
> echo "There are no native code compilers on arch $(shell dpkg
> --print-architecture) \
> so this package arch-dependant part should not build on it." ; \
> fi
> binary: binary-arch binary-indep
> .PHONY: build clean binary-indep binary-arch binary install
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
The easy way is the wrong way, and the hard way is the stupid way. Pick one.
Reply to: