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 [cjwat...@debian.org]
