Re: packages expected to fail on some archs
On Sun, Sep 11, 2022 at 11:07:13PM +0300, Adrian Bunk wrote:
> On Sun, Sep 11, 2022 at 05:08:57PM +0200, Samuel Thibault wrote:
> >...
> > The issue we see is that some DDs end up setting a hardcoded list in
> > the "Architecture" field, rather than just letting builds keep failing
> > on these archs (and then possibly succeeding after some time whenever
> > somebody contributes a fix upstream that gets propagated to Debian).
> >...
>
> I'd say it is the best solution when a package needs non-trivial
> architecture-specific porting for every architecture it supports.
>
> With "non-trivial" I mean not just adding a new architecture to a few
> #ifdefs, but serious upstream porting efforts. E.g. valgrind does not
> support riscv64, and if it would ever gain the support in a new upstream
> version I'd expect the maintainer to add that to the Architecture field
> when upstream announces support for a new architecture.
>
> But Architecture lists for expressing e.g. "64bit" or "little endian"
> are a real pain for everyone working on bringup of a new port.
>
> Which happens far more often than most people realize.
>
> There is not only riscv64 (64bit, little endian).
>
> Ports is about to start building for arc (32bit, little endian).
>
> There are people working on ports like arm64be (64bit, big endian),
> loongarch64 (64bit, little endian) and many other ports that might
> never end up being built in the Debian infrastructure (but some of
> them might get built by derivatives).
>
> Architecture lists containing all 64bit ports or all little endian
> ports create much extra work for anyone adding support for a new 64bit
> little endian architecture.
The problem is that if you want to exclude an arch explicitly, you have to
list all archs you want to build it on. IOW, I'm missing an easy way to say
"not on THIS architecture", somthing like "[!armel]"
There are a few packages I take care of which make trouble on some archs or
simply do not make much sense to run on those low-end archs. They compile
there beautifully, or at least the usually do, (which then creates a lot
of maintainer overhead then, because out-of-date…)
I was spending siginifant time in the past weeks on such a package, to fix
autopkgtests issues specific to that arch -- unsuccessfully, I disabled the
tests in the end --, where noone will ever use that package. I was very close
just to do what Sam asked us not to do. (And I agree with him that this is not
good.)
I don't actually believe people are using them on that arch, because if they
would, I would get bug reports about them… Upstream agrees with that: Although
off-topic, I would be eager to know if there is anybody using $PACKAGE on an
s390/System Z?"
> > Samuel
>
> cu
> Adrian
>
Reply to: