Re: Discussion about why GNU/Linux system upgrades cause old programs to break

"Dr. Arne Babenhauserheide" <[email protected]> Tue, 11 Aug 2026 23:23:30 +0200
Newsgroups	gmane.emacs.devel
Message-ID	<[email protected]>
Arsen Arsenović <[email protected]> writes:

> glibc, binutils and gcc releases are tested by various distros
> rebuilding their software against them.

This leaves out one part: distros often patch packages that do not
build after an update, to make it possible to update.

But this does not help programs that aren’t packaged in the distro.

They can also file bugs against the new libraries, compilers, etc, that
cause unchanged programs to no longer compile. But this requires
upstream to treat such breakage as problem that needs to be fixed.

Where (in the spectrum between always patching programs and always
ensuring compatibility from libraries/compilers/…) this work is done is
a community decision. Though often not taken explicitly but by doing
work where it seems to be done the fastest.

Not an easy one, and not one that is always answered the same way, but
still a decision.

One that I’ve seen taken without considering unpackaged programs.

>> You make it sound like a sin, but I happen to think it's a virtue.
>> Backward compatibility is an important aspect of being user friendly
>> in my book.

> I'm sure many more hours have been spent tracking down stuff that
> could've been prevented by stronger diagnostics than have been spent
> trying to compile old code.

I think here is a misconception: when an update to the compiler breaks
my previously compiling code, I am usually not working actively on the
project. It hits me while I have no time and energy to fix it. I updated
the system, after all, not my program.

And I usually cannot decide not to update the system, because security
issues require me to stay up to date.

And I may have many programs I wrote over the years. They work and I
started to depend on them, but I no longer change them. They are
complete.

If breaking of backwards compatibility occurs often, the regular
maintenance work required just to keep my setup working becomes
overwhelming after some time.

Example: I had to give up several Python projects I liked a lot because
of such problems. And I think that that’s bad. I use Python a lot less
due to that experience.

Second example: it took a lot of communication work to keep Lilypond
using Guile after Guile 2.0 broke the performance requirements Lilypond
had. Continuing after the performance reached a simliar level again.

> But, backwards compatibility in this instance means relaxing compiler
> diagnostics, thus making the compiler less strict. This is universally
> a disservice to users.

In these absolute terms I consider this statement to be wrong.

The alternative is not a compiler that can’t be strict, but one where
strictness is opt-in.

That turns a problem of breaking programs into a communication problem:
teaching people to activate the stricter mode for new projects.
(also see the later answer)

> Indeed, the case I showed in my last email with 'reallocarray' was
> exactly such a case: the user of flex "benefited" from default backwards
> compatibility, only to get a program that was slightly broken under
> specific conditions.

Those conditions only happen when usage changes. In the situation where
the program is currently being used, it works correctly.

> we've been teaching students that "this code is not correct but the
> compiler ignored it because old code exists, but you shouldn't ignore
> it" (to very little effect).

This means addressing a communication problem by a technical change that
broke existing tools.

I understand the reasoning for the change, but seeing the collateral
damage it does (most of which won’t be visible to the ones doing the
change), I do not like it.

Hyrum’s Law does not mean to give up on compatibility. Instead it states
that “changes to the system must maintain these performance
characteristics to continue functioning for its consumers” and “the
implicit interface constrains your system design and evolution”
-- https://www.hyrumslaw.com/
Not a license for breakage but a warning that compatibility goes deep.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
https://www.draketo.de
signature.asc (application/pgp-signature, 1.1 KB)