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

Arsen Arsenović <[email protected]> Mon, 10 Aug 2026 13:58:17 +0200
Newsgroups	gmane.emacs.devel
Message-ID	<[email protected]>
Richard Stallman <[email protected]> writes:

>   > Trying to run old versions of Emacs I've built myself on that very
>   > system:
>
>   >   eliz@fencepost:~$ emacs-28.x/emacs-28.0.90/src/emacs -Q
>   >   eliz@fencepost:~$ emacs-27.x/emacs-27.2/src/emacs -Q
>  
>   >   emacs-27.x/emacs-27.2/src/emacs: error while loading shared
>   >   libraries: libgtk-3.so.0: cannot open shared object file: No such
>   >   file or directory 127 eliz@fencepost:~$
>
> It looks like 28.x did work, because you report no error message from it.
> But 27.2 failed.
>
> 27.2 was released in March, 2021.  That is 5 years ago.  I think we
> shouldn't break programs that quickly!  I think our tools should
> continue to support a program for many more years than that.
>
> Now that I have specific reports, I can discuss them with maintainers.

The program didn't necessarily break in this example; the admin removed
libraries that the program was linked against.

If I removed libraries that my copy of Emacs 32 was linked against, it'd
also "break" in the same manner, even though the Emacs 32 I have
installed was built ~18 hours ago.

More broadly speaking, note that, IME as a distro maintainer, programs
quite rarely break due to issues in gcc, glibc, etc.

In the vast majority of cases, "breaks" are in things that previously
only worked by coincidence.

For instance, the example Eli gave, of programs "breaking" because GCC
versions up to 14 failed to properly diagnose invalid C99, the correct
interpretation is that the programs were only "working" (in air-quotes,
because they cannot possibly be considered working, the same way as
someone falling off a cliff is not truly flying) because GCC in
particular did not enforce language rules.

In reality, the programs have been broken for decades, often in subtle
ways, for instance by silently being compiled into wrong code.  Indeed,
such miscompilations were among the reasons the diagnostics were
strengthened.

Were we to keep this broken status quo, of having a compiler that fails
to diagnose incorrect programs, because people, 20+ years in, were not
correcting their habits of writing incorrect code?

In my opinion, said habits are a reason to correct the status quo to
start diagnosing incorrect code.

I don't care to relitigate that discussion further, it went on long
enough on the GCC mailing list when it initially happen.  We've put in
the effort of correcting existing programs, and
https://gcc.gnu.org/gcc-14/porting_to.html was written to help everyone
else deal with the "break".

I can't recall any actual breaks (i.e. not something like what was
described above) in the last five years, so I'd argue we don't break
programs that quickly.  All the breaks I can remember are simply
instances of Hyrum's Law.
-- 
Arsen Arsenović
signature.asc (application/pgp-signature, 418 B)