Colin Watson wrote... > On Thu, Nov 10, 2016 at 08:52:15PM -0800, Nikolaus Rath wrote:
> > That's a good theoretical argument. But in practice, I think the subset > > of architectures for which bar works correctly will always include > > amd64, and John D. Rebuilder will have access to such a box for sure. > > We know this not to have been the case in the past. > https://bugs.launchpad.net/launchpad/+bug/217427 mentions the cases of > palo (hppa), openhackware (powerpc), and openbios-sparc (sparc). > (People often suggest cross-compiling for this, and that can certainly > be a good solution in some cases, but please bear in mind that in the > general case that still only reduces the problem to "can only build on > architectures where somebody's uploaded the necessary cross tools".) That's a slightly different scenario since I'm just about to rebuild arch:all packages, so there's no need for cross tools. > There is currently one package in the Debian archive (pixfrogger) that > declares "Build-Indep-Architecture: i386" in its .dsc because, even > though it builds an architecture-independent binary package, building it > requires a package that's only available on 32-bit architectures. *That* is really helpful as it provides a generic solution for my problem: The maintainer can provide an architecture hint for any rebuilder. Is there a more formal specification around? I understand the comment in the diff[0] the header may carry a list of architectures, not just just a single one. That's the right thing. [0] http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/17338/lib/lp/soyuz/tests/test_build_set.py (aside, codesearch revealed there is a second source package: Also edk2 uses "XS-Build-Indep-Architecture". For amd64, though.) > As I allude to in > https://lists.debian.org/debian-devel/2016/11/msg00457.html, I think the > best answer is for Debian's buildd infrastructure to follow through on > implementing Build-Indep-Architecture. Seems reasonable. My intention is rather to make the life easier for folks downstream, like rebuilding and backports. As there's a workaround available now, I feel less reluctant to reveal the real packages: "foo" is 3270font, "bar" is fontforge | fontforge-nox. The bugreport for the latter is #831425. Christoph
signature.asc
Description: Digital signature
