Re: Building architecture:all packages
On Sat, Nov 12, 2016 at 03:13:54PM +0100, Adam Borowski wrote:
> On Sat, Nov 12, 2016 at 09:56:01AM +0100, Christoph Biedl wrote:
> > Colin Watson wrote...
> > > 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
Er, obviously it's part of Launchpad. That's not a "problem" when I was
presenting it merely as an example.
That said, most of the hard work is done in
lib/lp/soyuz/adapters/buildarch.py:determine_architectures_to_build,
which uses no other parts of Launchpad and could easily be transposed to
some other system.
The problem for somebody implementing this in Debian would not be that
the logical implementation of this field is Launchpad-specific; it would
be the different overall models for dispatching builds. Nevertheless, I
don't believe I've ever heard a serious developer complain about having
too much example code.
> * it supports only a single build-indep architecture rather than a list
Not so; you have misread the code. It is a list of architectures that
architecture-independent binary packages can be on.
> 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",
No. XS- doesn't mean "unofficial"; rather, it means "copy this
user-defined field to the output .dsc file" (see
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s5.7).
There is precedent for newly-defined fields starting out this way until
they become well-established enough that dpkg copies them by default and
they're added to policy, for example Vcs-*. The objection that this new
field cannot be used because it's been introduced using the perfectly
normal way to introduce new fields is not a reasonable one.
> I propose the new field to be a list per the usual architecture
> syntax.
Fortunately, since it already is, there is no need for a new field.
> > > 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.
dose is used only to determine whether a source can be moved from
BD-Uninstallable to Needs-Build in the context of a given set of Sources
and Packages files. The rest of this sounds a lot harder to do in the
context of wanna-build than it is to say; even if it were implemented,
it would no doubt require some way for maintainers to control it.
(This would all be a lot easier if wanna-build had adopted the model of
simply having a flag on each build that says whether it should build the
arch-indep parts in addition to the arch-dep parts, and dispensing with
the separate Architecture: all buildds. Then maintainers wouldn't have
to worry so much about making arch-indep-only builds work, which were
fairly novel at the point when these buildds were introduced, and doing
this kind of thing wouldn't require setting up a separate buildd on each
architecture.)
> 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).
I agree that pixfrogger should declare a list of architectures in
Build-Indep-Architecture, perhaps simply matching those declared in
fenix's Architecture field (since there's no suitable wildcard syntax
for "any 32-bit Linux architecture").
> 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 mentioned above, your reading is incorrect. Of course a rewrite is
needed, but unless somebody demonstrates an actual incompatibility then
there's no need to pick a gratuitously different name.
--
Colin Watson [cjwatson@debian.org]
Reply to: