[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Building architecture:all packages



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

Attachment: signature.asc
Description: Digital signature


Reply to: