Re: help with package restricted to specific arches
> From: Matthew Palmer <mpalmer@debian.org>
>
> On Sun, Mar 20, 2005 at 06:37:08PM -0500, Richard C Bilson wrote:
> > I maintan a source package, u++, which builds two packages: u++, which
> > is arch-specific, and u++-doc, which is arch-indep. The u++ binary
> > package can only be built on certain Debian architectures.
> >
> > The problem is that now I have a bug based on the fact that building
> > the arch-specific package fails on the other, unsupported,
> > architectures. I've tried three or four different solutions, and
> > nothing helps. Currently, I've conditionalized my binary-arch target
> > so that it does nothing on an unsupported arch, but then genchanges
> > dies when it finds that nothing was built.
>
> Have you set your Architecture: field to those arches your package can
> actually build on? That's the approved way of restricting your package to
> certain arches, and it should be picked up by the autobuilders and get left
> alone.
Yes, for the architecture-dependent binary package. But the doc package
is Architecture: all, i.e. my control file looks like:
Source: u++
Section: devel
Priority: optional
Maintainer: Richard C. Bilson <rcbilson@plg.uwaterloo.ca>
Uploaders: Matthieu Delahaye <matthieu@debian.org>
Build-Depends: csh | c-shell, g++ (>= 1:3.3), debhelper (>> 4.0.0), tetex-bin, t
etex-extra
Build-Depends-Indep: debhelper (>> 4.0.0), tetex-bin, tetex-extra
Standards-Version: 3.6.1
Package: u++
Architecture: i386 ia64
Depends: g++ (>= 1:3.3), ${shlibs:Depends}
Recommends: u++-doc
Description: Object-oriented concurrent language extensions for C++
Package: u++-doc
Architecture: all
Description: uC++ Annotated Reference Manual
This makes sense to me, but the build hosts insist on trying to build
everything, no matter what the Architecture field says.
> I'd encourage you to work on making the software build on all arches --
> especially since it seems like it'd be useful in lots of situations.
> Contact the failing arches' mailing lists for help in porting.
Oh, I agree for sure. But the nature of the software is such that
there's a significant amount of tricky assembly code involved, which
requires time and more than a few cpu cycles. I hope that we can get
there eventually -- the next release will have x86_64 for sure.
- Richard
Reply to: