Re: Do autopkgtest for non-listed architectures prevent migration?
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.
Best
Ole
Reply to: