Re: build-depending on a virtual package
On Sat, May 06, 2006 at 10:06:19PM +0300, George Danchev wrote:
> On Saturday 06 May 2006 21:03, Sven Luther wrote:
> > On Sat, May 06, 2006 at 08:47:57PM +0300, George Danchev wrote:
> > > 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 ;-)
>
> I'll remove that hack since it is rather uncivilized !
>
> > It seems to me, that your debian/control is badly set. Please have a look
>
> Oh, sorry Sven, the noise was bogus (seems my memory is out of memory
> lately ;-)
>
> Everything is fine after 1.0.10 ! E.g. if I simulate a non-native arch (like
> mips, m64k) by moving away my ocamlopt and ocamlopt.opt executables then just
> -byte binary packages are being produced, otherwise (e.g. on native arches)
> we produce them all. This is what we need for autobuilders and
> end-user-builders to be happy. I think I can close these bugs soon via
> NNN-done@...
>
> > at what we did with some other packages, where we use s substvar to set the
> > architectures that need native builds. If i remember well, spamoracle is an
> > example which does what you want to do.
>
> Spamoracle is where you pointed by at the very first place to look at and ara
> follows spamoracle ideology almost on a step by step basis. Thanks.
Ok.
...
You do know about :
$ cat /usr/lib/ocaml/3.09.1/native-archs
alpha amd64 arm hurd-i386 i386 ia64 kfreebsd-i386 powerpc sparc
and that this list should be used to generate the architecture field of the
control field for native packages ?
Ok, it seem to me, that given the spamroacle way, the problem is how the
buildd see a package with only arch: all and arch <native archs> packages, and
thus don't know what to do with it.
Friendly,
Sven Luther
Reply to: