Re: Do autopkgtest for non-listed architectures prevent migration?
On 1/24/22 11:36, Ole Streicher wrote:
> Helge Deller <deller@gmx.de> writes:
>> On 1/24/22 09:10, Ole Streicher wrote:
>>> Wookey <wookey@wookware.org> writes:
>>>> If the package builds on the 32bit arches then I would advise that you
>>>> let it build. We always try to build for all arches in debian and it
>>>> is very annoying if you have say an armhf machine and something is not
>>>> available just because there was some test failure so upstream simply
>>>> excluded builds completely. Packges should only be excluded on an arch
>>>> if they are known not to build or to be genuinely useless there.
>>>
>>> I would disagree here: If we can't support a certain package on a
>>> platform, then we shouldn't build it there. If neither upstream nor the
>>> Debian maintainer is going to support armhf, then it should not be built.
>>
>> I'm not sure if there is a misunderstanding here.
>> I think every package (unless it doesn't fit to a platform like a boot loader,
>> or the target architecture is really not meant for that package)
>> should be *built*. It may fail tests, in which case it should still be built,
>> but the build should be marked failed and as such no *binary* package
>> should be produced and uploaded.
>> But since it was built, platform maintainers may see it, can check the
>> build logs and may help to fix.
>>
>> The worst thing for arches is, if a package is being *excluded* from building
>> on certain arches just because there was a build- or test error.
>> That way nobody will notice and there will never someone look into it.
>
> Users of the platform may request the package if they need it (and they
> are relevant people for us). And attempting to build the package on such
> a platform is as easy as adding the architecture to d/control for the
> user. And porters can also just check which packages are not built on a
> platform.
Yes, everything is easy and "just doable".
For you it's just to modify one package in that case.
The problem for me as maintainer of an architecture (in my case parisc, which
is big-endian and 32bit userspace) is, that I then need to search which package
is missing, contact each package maintainer by himself, ask him, look again, ...
Usually if a package fails on one big-endian platform it often fails on other
big-endian platforms too.
Same for 32bit- vs. 64-bit.
So, if I or someone else fixes a big-endian build issue, it fixes it most of
the time for multiple architectures.
That's why I'm saying that you shouldn't exclude by default a *specific*
architecture. The problem is often not bound to that architecture, but by
the specifics which define that architecture (endianess, 32/64-bit, ...).
Helge
Reply to: