3 ms·

Reifying the toolchain dependency is the point. If you don't do this, you're fucked anyway.

by emidln 3y ago

ploxiln 3y ago
So, how have linux distros worked for the past 25 years? Many independent projects write commonly used libraries and/or tools in C, and then each distro takes those and builds them with a slightly (or significantly!) different toolchain ... obviously it has worked pretty well. The pressure to work for all reasonable toolchains is good for software quality, instead of depending on quirks of a very particular toolchain to mask some bugs or nonstandard behavior dependency.
- emidln 3y ago
  You bump the version gcc.spec in say, Fedora rawhide. What happens when random package foo doesnt compile with it? Foo is fixed or you skip that gcc version. Unless foo is very important and very hard to fix, you fix foo. Distros already enforce a consistent toolchain. Arch, Debian, Fedora, Gentoo, etc.
  - ploxiln 3y ago
    A distro uses a consistent toolchain, but doesn't write most of the code. The projects writing the vast bulk of the code, like linux, git, firefox, gtk, qt, openssl, curl, etc, don't strictly control the toolchain, and it does vary between distros and distro releases. Distros like Arch and Alpine keep the patching to a minimum, most packages need no patches. RedHat/Fedora and Ubuntu do patch significantly more. Debian is in the middle ... there was an infamous incident where they patched openssl to fix an uninitialized-memory warning, and caused a huge security issue for many people: https://www.schneier.com/blog/archives/2008/05/random_number_b.html https://www.schneier.com/blog/archives/2008/05/random_number... (yes, openssl sucks, but still.) So this is why distros take their cleanup patches upstream. Distro patches are for real observed bugs that aren't fixed in an upstream release (or not in the desired major release branch), or to just disable -Werror in projects that don't know better.

Reifying the toolchain dependency is the point. If you don't do this, you're fucked anyway.

by emidln 3y ago

Reifying the toolchain dependency is the point. If you don't do this, you're fucked anyway.

So, how have linux distros worked for the past 25 years? Many independent projects write commonly used libraries and/or tools in C, and then each distro takes those and builds them with a slightly (or significantly!) different toolchain ... obviously it has worked pretty well. The pressure to work for all reasonable toolchains is good for software quality, instead of depending on quirks of a very particular toolchain to mask some bugs or nonstandard behavior dependency.

emidln 3y ago
You bump the version gcc.spec in say, Fedora rawhide. What happens when random package foo doesnt compile with it? Foo is fixed or you skip that gcc version. Unless foo is very important and very hard to fix, you fix foo. Distros already enforce a consistent toolchain. Arch, Debian, Fedora, Gentoo, etc.
- ploxiln 3y ago
  A distro uses a consistent toolchain, but doesn't write most of the code. The projects writing the vast bulk of the code, like linux, git, firefox, gtk, qt, openssl, curl, etc, don't strictly control the toolchain, and it does vary between distros and distro releases. Distros like Arch and Alpine keep the patching to a minimum, most packages need no patches. RedHat/Fedora and Ubuntu do patch significantly more. Debian is in the middle ... there was an infamous incident where they patched openssl to fix an uninitialized-memory warning, and caused a huge security issue for many people: https://www.schneier.com/blog/archives/2008/05/random_number_b.html https://www.schneier.com/blog/archives/2008/05/random_number... (yes, openssl sucks, but still.) So this is why distros take their cleanup patches upstream. Distro patches are for real observed bugs that aren't fixed in an upstream release (or not in the desired major release branch), or to just disable -Werror in projects that don't know better.