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
