Re: Bug#336283: ara: [m68k] FTBFS
On Friday 04 November 2005 16:49, George Danchev wrote:
--cut--
> > > autobuilders build with dpkg-buildpackage -B, and build only
> > > binary-dep. Not sure if the contrary is possible though. binary-indep
> > > parts are only built by the original builder and not touched at all by
> > > the autobuilders, and as thus the bytecode-only part need not be built
> > > on any random arch.
> > >
> > > See the spamoracle package on how this can be done, and it has to my
> > > knowledge never caused any problem with the m68k buildd.
> >
> > This is where I've been looking at ;-) The only difference is that you
> > create an "empty" native package [1] on non-native architectures (m68k)
> > without ocamlopt.{opt) and this makes dpkg-genchanges happy, whilst it
> > is not created in ara and I got warnings that these are listed in control
> > file but not in debian/files (-byte packages are built ok). I should
> > figure out why such "empty" native package is not created with ara on
> > these arches.
Well, I think I have a solution [1] ... hm a little bit hackish and I'm still
not sure if it will hit something else though. Basically what we are trying
to solve is a building various arch-specific packages from a common source
package depending on the compilers (not)available on certain architectures
only. E.g. one source package:
-> bytecode debs can be built on all arches
-> native debs also can be built on all arches but with diferrent content,
e.g. no native binaries if no such compiler available for them.
For instance: We do not have ocamlopt/ocamlopt.opt on m68k,mips,mipsel,s390 to
build the arch-dependant binaries, but these users and autobuilders [2]
should be able to create such packages (although being empty) to satisfy what
has being listed in control file. So we end up having bytecode packages built
and empty native packages (no binaries inside, just docs;-) if the ara source
package was being built on m68k,mips,mipsel,s390 by an user or by a daemon.
Then the Provides:, Conflicts:, Replaces fileds will do the trick to have the
proper packages (the -byte code ones) installed on these arches.
Let me know if you think that behaviour is healthy.
[1] svn co svn://svn.debian.org/ara
trunk/debian/rules.hack (swap your rules pls, a separate branch will be an
overkill I think)
[2] if accidently happened to be scheduled for them, but being listed in the
dak/srcdep/Packages-arch-specific should prevent such schedules, so we will
make just our local builds users happy, see #290338, #336283 ;-)
--
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: