Rethinking Fedora's compiler policy [LWN.net]

Rethinking Fedora's compiler policy

Posted May 1, 2021 20:03 UTC (Sat) by NYKevin (subscriber, #129325)
In reply to: Rethinking Fedora's compiler policy by nim-nim
Parent article: Rethinking Fedora's compiler policy

Realistically, upstream is going to do what is best for upstream, and downstream will then do what is best for downstream. If upstream only supports compiler (or build toolchain, container system, etc.) X, and downstream would prefer to use compiler Y, then downstream has a limited set of options:

1. Suck it up and use X anyway.
2. Convince upstream to support Y. In practice, this probably involves directly helping upstream to maintain support for Y, rather than merely filing bugs whenever Y breaks.
3. Fork or patch the package to support Y.
4. Drop the package.

Although #2 is a possibility, upstream has an absolute right to refuse it, and it is not very productive for downstream to complain about this choice once it has been made. Therefore, it's probably a Good Idea for downstream to have a standardized process for choosing between options 1, 3 and 4. That does not mean that every package should get the same choice, of course, just that there should be a process for making this decision (other than "everyone gets on the mailing list and argues for three days").

to post comments

Rethinking Fedora's compiler policy

Posted May 1, 2021 22:28 UTC (Sat) by rodgerd (guest, #58896) [Link] (5 responses)

Three imposes huge and unreasonable work on maintainers, and 4 is holding the distro's users hostage.

Really, if people choose not to use a given (compiler, init system, whatever), trying to use distro terrorism to force them to is admission of abject failure.

Rethinking Fedora's compiler policy

Posted May 1, 2021 23:08 UTC (Sat) by pebolle (guest, #35204) [Link]

> distro terrorism

How to top this? Non of distro nazism, distro communism, distro neo-liberalism, distro colonialism really work for me. So it seems you coined a winner here.

Thanks for making free software look even more like a lunatic fringe!

Rethinking Fedora's compiler policy

Posted May 2, 2021 1:27 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (3 responses)

> Three imposes huge and unreasonable work on maintainers, and 4 is holding the distro's users hostage.

So what?

Upstream produces tarballs. Downstream can take them or leave them. If upstream is so inclined, it may voluntarily decide to make changes to accommodate downstream's wishes. But there is no general obligation for upstream to do this, and it would be quite absurd if there was (consider the number of different distros out there). If downstream responds to this reality with hostility and accusations of "holding users hostage," then it is entirely reasonable for upstream to killfile downstream's emails.

Rethinking Fedora's compiler policy

Posted May 2, 2021 10:55 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

But if, say, downstream relies on llvm (which is not compatible with GCC?), then upstream is basically saying "we don't want you on our distro". Which in the long run is the distro cutting off its nose to spite its face.

If people want to use a different compiler because it supports features GCC can't - or in certain circumstances WON'T - support then you have all the makings of a nasty stand-off down to the distro's intransigence.

I think this is what's getting peoples noses out of joint - the distro forcing technically bad choices onto downstream.

Cheers,
Wol

Rethinking Fedora's compiler policy

Posted May 2, 2021 15:27 UTC (Sun) by pizza (subscriber, #46) [Link]

> I think this is what's getting peoples noses out of joint - the distro forcing technically bad choices onto downstream.

And vice-versa.

Rethinking Fedora's compiler policy

Posted May 2, 2021 14:56 UTC (Sun) by jccleaver (guest, #127418) [Link]

> Upstream produces tarballs.

If only... :/