Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] Please, let's stop breaking system ABI on spell updates! (Bug 16100)

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Thomas Orgis <thomas-forum AT orgis.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] Please, let's stop breaking system ABI on spell updates! (Bug 16100)
  • Date: Wed, 9 Jan 2019 18:04:43 +0100

Dear fellow mages,

I'm fed up with SMGL. I am fed up with it constantly pulling ABI from
under its own feet. This is stupid, and we know it. We knew it at least
since 2006 (https://bugs.sourcemage.org/show_bug.cgi?id=13121). It's
also embarrassing that we still don't build in a sandbox and have no
staging for a group of spells for atomic updates (one switch between
old and new KDE, not break old, spend hours building new, maybe install
new). But the ABI breakage is just silly stupid.

To recap:

1. We update $SPELL, which installs libfoo.so.$(($SOVERSION+1)) after
removing libfoo.so.$SOVERSION.
2. We just broke the system ABI as libfoo.so.$SOVERSION is gone.
3. Profit?

This used to just mean that any user-built binaries not under package
management are potentially broken without even a shrug. But in recent
times, it means that gcc or make are broken due to isl, icu, whatever.
In earlier times it was gettext. Curses and readline are also all-time
favourites.

I recently updated (still trying to) an install of about two years of
age. Without cache tarballs, I'd been lost the first time make broke,
even before gcc, AFAIR. Adding hacks to some core spells like glibc
(how obvious!) to temporarily keep the installed lib version around
dances around the actual point, which is:

Do not delete libraries that are still in use by anyone!

This should be so obvious that we all deserve some serious moment of
being ashamed of our conduct. How can we, year after year, use,
support, work on a system that only survives updates by sheer luck, and
if that luck fails, add local workarounds that try to keep bash loading
with some rescued earlier libreadline in some temporary place, not
anticipating (or failing to accept the reality of) the case that things
can break on a larger scale?

Hence, my proposal outlined in

https://bugs.sourcemage.org/show_bug.cgi?id=16100

. It is not the first at all, just the first from me. Let me make it
clear that I am against any hack only considering special spells: Any
public (found by ld.so) libfoo.so.x vanishing from the system is a
non-trivial change that should not happen without notice. This is just
bad behaviour. Since we do rolling-release, we cannot expect users to
check all local software using system libraries on each spell update.

We have enough problems with actual spell API breakage and untested
configurations. We should stop creating additional ones by
unnecessarily removing libraries before even the managed packages using
them are re-built.

Getting back to the intial steps of breakage during spell update, I
want this picture instead:

1. We update $SPELL, which installs libfoo.so.$(($SOVERSION+1)) in addition
to libfoo.so.$SOVERSION. The .so symlink is changed, of course, as
well as libfoo.a.
2. We continue system usage and further updates, possibly removing all
usage of libfoo.so.$SOVERSION.
3. User decides that they want to get rid of old libs lying around. Something
like
cleanse --old-libs $SPELL will do just that ($SPELL optional to
avoid removing other libs).

It is rather obvious from the concept of soversions that it is entirely
possible to have multiple versions of the library around. Why do we
have to limit that to one?

It may be dirty just to consider /lib/libfoo.so.* and no other parts of
the ABI (perhaps versioned auxilliary files needed by the library), but
_those_ can be added for specific spells later. All the basic breakage
I had so far was about simple libraries missing.

Of course, the proper way would be to go full NixOS and keep the whole
old version files around, but I think just not deleting the libraries
goes a long way to get the needed operational safety without changing
the basic model of our distro.

Another approach I remember created a dummy spell for the files that
are not deleted. This is also a valid option. My approach seemed
simpler to me: just filter what files get deleted on dispel. It is open
to debate if having artificial spells (with some convention on naming?)
is more clean than a flat list of orphan files
in /var/log/sorcery/protected/$SPELL-$VERSION. Whatever solution
prevails: Please let's decide on _anything_ and ship it.

Currently, SMGL is broken in so many ways. We should fix some of them
where it is actually not that hard. Then in 10 years we can again think
about untangling circular dependencies, or about scanning library
dependencies on _install_ to record actual spell dependencies.

Please discuss on bug 16100 and let's have some library protection in
sorcery soon.


Alrighty then,

Thomas



  • [SM-Discuss] Please, let's stop breaking system ABI on spell updates! (Bug 16100), Thomas Orgis, 01/09/2019

Archive powered by MHonArc 2.6.24.

Top of Page