Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
On Mon, Aug 20, 2018 at 09:28:30AM +0200, Wouter Verhelst wrote:
> On Mon, Aug 20, 2018 at 12:15:00AM +0300, Adrian Bunk wrote:
> > How should we handle architecture-specific patches properly inside
> > Debian?
>
> Why should there ever be architecture-specific patches?
>
> I get that there sometimes need to be vendor-specific patches, because
> defaults may differ between distributions. But why on earth should
> defaults differ between architectures? That just makes no sense. Things
> like uintXX_t and htonl() should take away most architecture-specific
> differences, and then all that remains are things like ensuring
> alignment is done right. You don't need patches for that; you need
> bugfree code for that.
>...
Are we discussing bugfree code or are we discussing reality?
As an example, the non-release architectures of Debian are either
brand-new (riscv64) or fringe with usually brittle upstream status
in the toolchain (the other 13 non-release architectures).
Now look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412
"Keywords: deferred" means "This bug was deemed too risky to attempt to
fix during stabilization stages. Deferred to a development stage of a
subsequent release." AKA "Target Milestone: 9.0"
The bug seems to be rare enough on x86 to warrant that.
On ia64 this bug breaks most code that builds with -O3,
Qt and Pyhon 3.7 were among the first FTBFS.
The fix will likely be in generic code in gcc.
Should the gcc maintainer apply a backport of a non-architecture
specific change to the compiler used in the buster release, if upstream
considers it too risky for the gcc 8 branch[1] and the fix is important
only for a non-release architecture?
Applied only on ia64 the situation is different.
On ia64 the alternative would be a lot of FTBFS bugfixing
work with workaround patches submitted to a three digit number
of packages.
And this can happen even on release architectures in a release.
In src:gcc-6 the fix for #727621 [2], which is required for
building LLVM on armel, is applied only on armel in stretch.
cu
Adrian
[1] perhaps the fix for this specific bug will turn out to be simple,
but let's assume there will be a fix and it will not be backported
to the upstream gcc 8 branch
[2] https://sources.debian.org/src/gcc-6/6.4.0-20/debian/patches/pr64735.diff/
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: