Re: stop building the native mips* packages from the gcc-11, binutils and gcc-defaults packages

[YunQiang Su <syq@debian.org>]

Matthias Klose <doko@debian.org> 于2021年5月6日周四 下午5:19写道：
>
> Hi syq,
>
> when uploading gcc-11 to unstable, I'll fail the build for mipsel and mips64el.
> Please start building gcc-11 from it's own source package for the mipsel and
> mips64el binaries.
>

Yes. It is our problem to leave the upstream bug to Debian.
Anyway we fixed them now.

> The past years have shown for me, that I'm spending too much time caring for
> mipsen issues, and as long as these archs are still release architectures, I am
> trying to reduce my involvement with these.
>
>  - For the past four or five years, Debian didn't complete any
>    decision process for release architectures, maybe for limited
>    spare time, maybe because decision makers are biased.
>
>  - Compared to other release architectures I see more issues on
>    mipsen targets than on other release architectures, also
>    there is no mips*-linux target mentioned in GCC upstream either
>    as a primary or secondary release architecture.  I don't see
>    mips-elf as an adequate target.  mips*-linux development
>    seems to happen within Debian, like KFreeBSD and the Hurd.
>    These are also not release architecture anymore.
>    Looking at the gcc-testresults, the only test results
>    posted are from the Debian builds, so nobody else in the
>    community seems to build for mips*-linux.
>

Yes. it was like it. While the problem is in the progress of improve.
We just donate some new machines to GCC to act as testbed.

> The extra packaging shouldn't be much overhead, adding a gcc-11-mipsen package
> which only builds the native packages for mipsel and mips64el.  For the future,
> the native mipsen binutils packages can also be built from the binutils-mipsen
> source packages, as the native mipsen gcc dependency packages from the
> gcc-defaults-mipsen source package.
>

Thanks. I have a try to generate native packages from gcc-defaults-mipsen, while
it may make it too complex than current version.

> Matthias