On Sun, 24 Mar 2024 at 13:09:02 +0100, Samuel Thibault wrote:
> Simon McVittie, le dim. 24 mars 2024 11:59:50 +0000, a ecrit:
> > For the specific example of pipewire, I've suggested temporarily
> > dropping that feature from pipewire on the affected architectures
> > <https://bugs.debian.org/1067558> which would get the rebuilds further
> > along (particularly if it unblocks weston, which lots of packages use
> > in their tests). There are various places where targeted changes like
> > this can unblock a whole tree of dependencies.
>
> Could we use build profiles for this? That'd avoid full uploads, and
> document for architecture bootstrapping.
Only if a porter is willing to do a binary build with the relevant
build profile on each of the affected architectures, and upload it as
binary-only, after making a note to get it binNMU'd later. The official
buildds for release architectures always build with no build profiles,
and do not have any way (that I'm aware of) to vary this.
The porter-binary-upload approach is necessary for the actual bootstrap
phase of the dependency stack, but doesn't seem to be scaling well in
higher layers, because the number of porters is limited. I'd prefer
to give porters the opportunity to work on more difficult issues where
their architecture-specific knowledge is actually relevant, so I'm doing
my best to unblock some of the dependency chains without having to block
on porter uploads.
However, I'm not an armel/armhf porter (and certainly not an hppa, m68k,
or powerpc porter) and I don't have the relevant hardware up and running,
so I'm not going to sign a specific binary build that I have no ability to
test. Similarly, there doesn't seem to be consensus on whether porterboxes
should be considered to be a trusted environment, so I'm not comfortable
with signing test-builds that have been done on a porterbox. I'm sorry
if my limitations are inconveniencing people: if other developers have
different policies and resources then they are welcome to take over.
When suggesting a cut-down version, what I'm often doing is suggesting
a change of the form "when building on 32-bit non-i386, always build
as though profile pkg.foo.bar was active" - although if there isn't
already a convenient build-profile to do this with, I admit I haven't
always been adding one, because that adds complexity, and I don't want
maintainers' response to my suggestions to be "that looks too hard, I'm
not going to touch this".
Build-profiles are at their most useful where they are "safe" or
"reproducible" (no functional effect on the built binaries, except
that some binary packages are skipped entirely), and in many cases
the features we're having to disable at this stage of the transition
*do* have a functional impact. I'd personally prefer for changes with
a functional impact to be documented in the changelog so that we know
they have happened, and built on the same trusted buildds as any other
official package.
smcv
