Re: build-depending on a virtual package
On Thursday 04 May 2006 15:05, Goswin von Brederlow wrote:
> Stefano Zacchiroli <zack@debian.org> writes:
> > On Tue, May 02, 2006 at 06:37:00PM +0200, Goswin von Brederlow wrote:
> >> Does it realy matter to have the ocaml-best-compilers? Do we realy
> >> need to save that extra 0.1s compile time by using the binary
> >> optimized compiled on some archs?
> >
> > My answer is: no.
> >
> > But still, on stuff like Coq it can be far from the 0.1s, it can be a
> > factor of up to 10x. As a user who rebuild from time to time package by
> > himself, having such build-dependency is a way to reduce the compile
> > time. I see it like a way to be kind with users rebuilding package by
> > their own.
> >
> > It would be wonderful to have a way for such a dependency to be just a
> > "hint", that sbuild can be free to ignore. But AFAIK there is no way to
> > do that.
> >
> > Cheers.
>
> Build-Depends: ocaml-nox | ocaml-native-compilers
>
> But that is of roughly 0 use, ocaml-nox will always be installed.
>
> The package should build the same way for users as it does for
> buildds, again to be deterministic. So it is out of the question to
> probe for ocamlopt.opt and use it if availbale. But debian/rules could
> check some environment variable, e.g. DEB_OCAML_OPTS, and change its
> behaviour if it is set.
>
>
> But back to the problem.
>
> Option 1) Just ignore it since there is only one package providing
> ocaml-best-compilers. Ignore "apt-get build-dep" breakage. They are
> partly a bug in apt anyway.
>
> Option 2) Create a meta package "ocaml-best-compilers" that depends on
> the best compiler for each arch.
Another build problem is that ara source package produces four binary
packages, but two of them (ara and xara-gtk) are not supposed to be built on
some arches (like m68k, mips...) since they lack the native code compiler.
We can make autobuilders happy anyway, but we can not prevent users of these
arches (m68k, mips...) to build the source package locally (see #290338,
336283) and see the failure.
Presently we show them a message explaining the reasons, but seems it is not
enough explanative for some users ;-). Also dpkg-genchanges and friends are
not quite happy when only two of the declared binary packages are being
completed. Is there any sane way to convince these tools that "we know what
we are doing" [tm] and to shut them up ?
I have a really ugly hack for rules which is able complete all binary packages
declared even on these arches lacking native code compilers. See rules.hack
at: http://svn.debian.org/wsvn/ara/trunk/debian/?rev=0&sc=0
(yes, that is ugly, but doable I think ;-)
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Reply to: