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
