Bug#846970: debian-policy: Proposal for a Build-Indep-Architecture: control file field
On Tue, Aug 01, 2017 at 07:47:47PM +0300, Adrian Bunk wrote:
> 1. Debian does not currently have non-amd64 binary-all autobuilders
>
> Stating that binary-all packages in the archive are always being
> built on amd64 would actually document the current status quo,
> assuming source-only uploads.
>
> AFAIR pixfrogger and pixbros that I converted from binary-all to
> an explicit list of all 32bit architectures were the last two
> binary-all packages in main that could not be built on amd64.
>
> These were pretty rare cases of requiring a 32bit-only package,
> and such a rare hack is better than mandating that Debian must
> add binary-all autobuilders for every architecture.
This is an essentially artificial argument that depends on the current
(IMO unnecessarily complicated) way in which Debian happens to implement
autobuilding of Architecture: all binaries. If they were just builds
that happened on the normal autobuilders with a slightly different
configuration, which would be perfectly possible, then nobody would need
to worry about the effort of adding them for every architecture; any
autobuilder would be able to build Architecture: all packages if it
needed to do so.
To me, as one of the maintainers of Ubuntu's autobuilding
infrastructure, this is a sufficiently obviously simpler approach that
I'm quite puzzled as to why the Debian buildd maintainers chose to
implement it the way they did; I did talk to Andreas Barth about it at
the time that he was doing the work, but I had the feeling neither of us
was quite understanding the other.
I can see the argument for not documenting this field in policy until
the autobuilding infrastructure is actually able to cope with it
(depending on how heavily one weights the downstream arguments), but I
do think that the capability would fall quite naturally out of a
better-designed infrastructure. I don't agree that your "explicitly
list all 32-bit architectures" hack is better than having the improved
infrastructure, even though it was probably necessary at the time.
> 2. We were not able to build all binaries in a release
>
> For aboot and palo we are shipping binaries in jessie that cannot be
> rebuilt in jessie since the build architecture is not part of jessie.
>
> Cross-compilers are available on amd64, and this is how palo and
> openhackware were fixed for stretch.
This has certainly been possible in some cases, but I still think it's
more simply done at the builder level. And for the "build architecture
not part of release" case, is it really worth shipping boot loaders for
architectures where we don't ship the rest of the architecture? The
rare case of systems building images for older releases could be handled
by just installing binaries from older releases.
--
Colin Watson [cjwatson@debian.org]
Reply to: