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

Richard Stallman <[email protected]> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > 'apt upgrade' does not also automatically run 'apt autoremove'.  Most
>   > admins, however, instinctively do.
>
>   > Including me.
>
> You've given a clear description of how `apt' dependencies
> sometimes cause deletion of older versions of libraries, which
> user programs sometimes need.
>
> I understand the logic behind this, but it regularly leads to problems
> for people using their own, non-system-managed programs.  And unless
> you're a sysadmin of the computer in question, you can't fix it when
> it happens.
>
> We should try to find some sort of solution.
>
> Here is one approach I thought of.
>
> When users link a program, and it links in a managed dynamic library
> that might later get replaced by a newer version, that could add the
> library to a system-wide list of "managed dynamic libraries that users
> use in their own programs".  This list would tell `apt autoremove' not
> to delete those libraries.
>
> It could record the users logins, too, and the program being linked,
> if the user does not say don't record it.
>
> When `apt autoremove' would remove library GTK2, but it is in that
> list so it doesn't remove that, it could remind the sysadmin to ask
> whether that user whether perse wants GTK2 to stay around.

Something like that could be implemented, but it may run into issues
with dlopen (of course, dlopen'ed libraries aren't linked against).

Or with files being renamed or removed (presumably, you'd want to toss
away diagnostics detected that way if the program the user built gets
removed, but, a renamed file appears removed).

There may be an alternative.

One could conceive of a program that parses an ELF and scours the
library search paths to collect all the libraries the ELF might use into
one place.  It could, then, adjust the RUNPATH of that binary to be able
to use the copies as fallback (and adjust the RUNPATHs of the copies,
etc).

Now, DT_RUNPATH isn't positioned exactly correctly in the library search
path for this, but maybe a new tag could be invented, that is placed
*after* the usual library search path.

The reason I say "as fallback" is because it'd be good if the user could
still receive updates for their libraries.

This doesn't catch dlopen, but, helpfully, the UAPI Group has defined
https://uapi-group.org/specifications/specs/elf_dlopen_metadata/ that
helps a programmer declare what libraries they may want to 'dlopen'.
So, we could cover /some/ dlopened libraries that way.

Another alternative is provided by Guix.  A non-sysadmin user can
get whatever packages they want using it without privileges.

But, that's quite a departure from the 'usual' system, and requires
relatively significant technical knowledge.

(PS: Your email client seems to have issues with UTF-8; it munges my
 last name in headers)
-- 
Arsen Arsenović

-----BEGIN PGP SIGNATURE-----

iQECBAEWCgCqFiEE/uKz0RP8AKMWLWBhUsKUMB6ixJMFAmp+N/cbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRUUyQjNEMTEzRkMwMEEzMTYyRDYw
NjE1MkMyOTQzMDFFQTJDNDkzEBxhcnNlbkBhYXJzZW4ubWUACgkQUsKUMB6ixJN2
owEA1b7QFz81fhlkb6Dg8FNu2BP4M2ILhu0uz9otqM2dJlgA/2PVCSrqw+cetY5V
nX94BanHxCkDFa8WszRlPbqlZjcF
=MusB
-----END PGP SIGNATURE-----