4 ms·

All true in theory, but in practice these mechanisms are worthless because for most libraries Debian developers are dropping older version of libraries immediat

All true in theory, but in practice these mechanisms are worthless because for most libraries Debian developers are dropping older version of libraries immediately after transition to the new version is completed. Want to to run a 3rd party binary that depends on an older library? You're favorite package was dropped during the transition? Tough luck. Your best bet is installing needed library packages from previous debian release and praying that'll work.

derefr 6y ago
True enough, but if stability is your desire, that is precisely why distros cut releases (and especially LTS releases) in the first place. If you want a program that can run without ABI-conformance changes for years and years, base it on an LTS release, and that LTS release will keep whatever ABI-major versions of the .so library-packages it shipped with updated (with security updates, at least) until the release's EOL. If you don't want ABI breakage, then don't dist-upgrade! But, this is also to say: if you're creating a new, greenfield project, or a new major version of your own app—and you haven't yet deployed it into the wild as a fixed binary that people rely on to continue running on their boxes between upgrades—then nobody else but you has any incentive to keep things stable for you. If you want to develop against the newest Debian release at any given time, then it's up to you to catch up to whatever the newest ABI-major versions of your deps are at any given time. That's a problem you've chosen for yourself.
pas 6y ago
Or Docker, or Nix, or LD_ env vars. It's annoying that sometimes major dependencies don't support side by side versions (libcurl! openssl as libssl!), but the solutions are well known and relatively simple. And much more maintenable than a Windows box.

4 ms·

All true in theory, but in practice these mechanisms are worthless because for most libraries Debian developers are dropping older version of libraries immediat

by kasabali 6y ago

derefr 6y ago
True enough, but if stability is your desire, that is precisely why distros cut releases (and especially LTS releases) in the first place. If you want a program that can run without ABI-conformance changes for years and years, base it on an LTS release, and that LTS release will keep whatever ABI-major versions of the .so library-packages it shipped with updated (with security updates, at least) until the release's EOL. If you don't want ABI breakage, then don't dist-upgrade! But, this is also to say: if you're creating a new, greenfield project, or a new major version of your own app—and you haven't yet deployed it into the wild as a fixed binary that people rely on to continue running on their boxes between upgrades—then nobody else but you has any incentive to keep things stable for you. If you want to develop against the newest Debian release at any given time, then it's up to you to catch up to whatever the newest ABI-major versions of your deps are at any given time. That's a problem you've chosen for yourself.
pas 6y ago
Or Docker, or Nix, or LD_ env vars. It's annoying that sometimes major dependencies don't support side by side versions (libcurl! openssl as libssl!), but the solutions are well known and relatively simple. And much more maintenable than a Windows box.