[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Architecture restrictions and arch: all binary packages



Hello folks,

I'm working on the next release of the OpenAFS packages, and I'd really
like to resolve a long-standing annoyance to the buildds that the package
at present currently causes.  But I'm not sure the best way to do it.

Of the architectures that Debian supports, OpenAFS does not support arm,
m68k, mips, or mipsel.  It's unlikely that it will in the forseeable
future; it requires a kernel component and no one seems to be working on
ports.

All of the binary packages are appropriately limited in the control file,
but since OpenAFS includes a kernel module, it also builds
openafs-modules-source, which is architecture: all.  Apparently, if I'm
following the history in #84530, one can't limit the architecture of the
source package if it needs to also build an arch: all binary package.

Right now, therefore, the buildds for those four platforms try to build
every OpenAFS release, install all its dependencies, and then error out in
the configure script.  This is doubtless a bit annoying to the buildd
admins, is a waste of buildd resources, and all around seems like
something that would be better to avoid.

There was one suggestion in the bug log from Goswin von Brederlow:

| 1. Build-Depend/Conflict on the architecture
| 
| Build-Depends: type-handling
| Build-Conflicts: mips, mipsel, ia64
| 
| That way an attempt to build on an unsuported architecture will fail
| with a Build-Conflict.

but in addition to seeming like kind of a hack, I'm not sure that this
will do anything other than produce a better error message.  I'd certainly
like to produce a better error message, and will do that if all else fails
(although I'm not sure this is the best mechanism to do so), but isn't
there any way to tag the package so that the buildds won't even try?

(Part of the problem is that the kernel source isn't *really* arch: all,
since it's pretty useless right now on those four platforms, but making it
arch-dependent is just wrong and a huge waste of space.)

Any suggestions gratefully accepted.  Thanks!

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>



Reply to: