Re: Building architecture:all packages
On Sat, Nov 12, 2016 at 09:56:01AM +0100, Christoph Biedl wrote:
> 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).
I see two problems in that code:
* it's Launchpad-specific
* it supports only a single build-indep architecture rather than a list
The latter has next to no practical effect, but I still feel it wrong to
knowingly write incomplete metadata when it'd be trivial to do it right.
As the code has to be rewritten for DAK/w-b/etc anyway, and the XS- prefix
can't be used because it's officially "unofficial", I propose the new field
to be a list per the usual architecture syntax.
> > (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.
Any arch:all package that ships some kind of BIOS/etc does require either
specific-native or cross tools. Having qemu and co depend on ten or so
foreign arch packages, some from second-class archs, is not a good idea.
> > 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.
Isn't this what dose3 is employed for? I'd expect it to notice the
build-deps are uninstallable on amd64, and move it to a (non-existant)
i386/armhf/... arch:all buildd.
If manually specifying that is needed, pixfrogger is another case that
should declare a list rather than a single arch: i386 is basically gone
other than hardware emulation on amd64, armhf is a better supported 32-bit
arch these days (at least counting porters and new gear).
> *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
My cursory reading of code that deals with the actual field disagrees, but
that's moot as the code can't be applied to Debian without a rewrite.
> > 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.
And derivatives, most of which build only a subset of architectures,
sometimes just one, like Rasbian (armhf only).
> 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.
With my 3270font maintainer hat on: I wouldn't even know of this if not for
the reproducible builds project, despite doing lots of rebuilds on various
architectures (albeit not really for this package). I guess there's a lot
of other arch-dependant failures for arch:all packages.
--
A true bird-watcher waves his tail while doing so.
Reply to: