Bug#846970: debian-policy: Proposal for a Build-Indep-Architecture: control file field
On Tue, Aug 01, 2017 at 11:56:58PM +0100, Colin Watson wrote:
> 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.
Thinking about it again, just making them binary-any would have
equally solved the problem - they would just have stayed forever
in BD-Uninstallable on 64 bit architectures.
pixfrogger and pixbros were "binary-all packages that depend and
build-depend on a binary-any package that is not 64bit-clean".
That's a very uncommon situation, and nothing that is expected
to happen again in the future.
The only XS-Build-Indep-Architecture left in Debian is for amd64 (sic):
http://sources.debian.net/src/edk2/0~20161202.7bbe0b3e-1/debian/control/?hl=11#L11
Do you currently have any packages left in Ubuntu that need this
building of binary-all on non-amd64?
> > 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.
qemu-system-ppc depends on qemu-slof and the already mentioned openhackware.
>From a build perspective this is the same problem of building binaries
for a non-release architecture in a binary-all package, and it is
already solved with the same solution (cross-build on amd64).
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: