Bug#904302: Why outlawing vendor-specific patch series would be a bad idea
On Mon, Aug 20, 2018 at 04:51:30PM +0300, Adrian Bunk wrote:
> 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.
Yes, but there's a huge difference here.
Compiling code for a given platform is not the same thing as running on
said platform. If the compiler runs correctly, then it doesn't matter
which platform it runs on; it's still the same compiler.
The architecture-specific issues that I was talking about, when they
occur in a compiler for a platform, can be patched perfectly safe, with
or without the agreement from upstream. If you see that a compiler
misbehaves when compiling *on* platform X but not when compiling *on*
platform Y (but in both cases compiling *for* platform Z), then you need
to fix the code on all platforms -- the ones where it is broken as well
as the ones where it is not broken -- and ship the fixed code. Hopefully
to upstream too, but definitely to Debian.
The architecture-specific code in a compiler that occurs when compiling
for a given platform needs to be built into *any* compiler which
produces code for that platform; so, not just in src:gcc-X, but also in
src:gcc-X-cross and src:gcc-X-cross-ports.
So even if we were to add code to dpkg-source to support
architecture-specific patches (which we don't currently and which I
think we definitely shouldn't), then this still wouldn't help the GCC
packages in Debian.
[...]
> 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.
No; it is applied only on compilers that produce armel *output* in
stretch.
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Reply to: