You are viewing hedgehogpainter

Previous Entry | Next Entry

bYnary incompatiDEbility


All I really need know I learned in kindergarten ... Come on, say you're sorry when you mess things up. Allright, we released a YaST (ncurses) update. It broke ncurses packager in openSUSE 11.1 and 11.2 for everyone. One could still use GUI (qt/gtk) packager or zypper CLI - instead, or to fix things up (e.g. to downgrade), but this is not exactly the thing that boosts user's trust in the distribution, is it? Many thanks to Marcus  for prompt response - a new update has  been released swiftly  and it can be downloaded by now. It was enough to rebuild ncurses packager against updated YaST ncurses UI lib ...

Logically, one could now ask "How comes you guys released such a crappy update? Hasn't it been tested at all?". Well, as Marcus already stated in bzilla, openSUSE update testing largely depends on those community members who use Update:Test repo and apply patches (almost) ready for the release before they hit official update repositories.
To improve the quality of updates (and to prevent buggy updates from hitting many users), we need more hero testers. What does it mean? Go subscribe Update:Test repo and/or look here how you can help maintenance team otherwise. Oh, and you may also talk your neighbour (sister, cousin, ... ) into doing the same :)

Moreover, in this particular case, it was few other little things that summed up and resulted in failure.
  • The original bug ("paging bug") this update was about to fix was reported against Package1 (yast2-backup), fixed in Package2 (yast2-ncurses) and the resulting patch crashed Package3 (yast2-ncurses-pkg). Package3 is one of approx. 80 YaST packages. Taking also update description into account, even a seasoned tester would probably pick the original module (yast2-backup) for testing here.
  • With dramatic increase in the popularity of zypper and "mainstreamness" of GUI tools, I wouldn't be surprised to find out that very few of our update testers actively use ncurses packager
  • This was the first yast2-ncurses update introducing ABI incompatibility since its split (package manager used to be integral part of the library in the past). We didn't have the experience "a dependent pack must be also included in the update"  yet

Wanted: plugin lib versioning know-how

When sh** hit the fan, my thoughts followed along this line: "Now, if we introduce some system of tracking ABI changes in YaST libs .. " (shared library versioning it is called, now I know it) "... and have dependent packages require the correct version of shared library, we can avoid breakages like this in the future." But alas, my visit to YaST core wizard made me pretty pessimistic. Not only YaST core doesn't encourage shared lib writers to version their libs correctly, it makes (in its current form) the versioning impossible. 

YaST core doesn't link against shared libs, it loads ( dlopen()s ) them on demand as plugins and the existence of different versions of plugins would complicate the situation ... So, my dear readers, if you happen to know some (preferably) open-source project that is already proficient in this i.e. it loads its components as plugins AND applies solid library versioning policy at the same time, let us (include MVidner the Wizard in the loop, too) know. Kingdom for know-how !

And now .... winter hibernation again.

Comments

( 3 comments — Leave a comment )
hatzfeld [salesianer.de]
Jan. 15th, 2010 01:18 pm (UTC)
Workaround
For those who are looking for a workaround on a server without X-server/GUI: Just start "zypper up".
https://www.google.com/accounts/o8/id?id=AItOawmAH6Htbv0kmniTLK3zGKxi1c7J5-EMh3w
Jan. 18th, 2010 12:16 pm (UTC)
plug-in versioning
We discussed it and came up with changing the plug-in loading API from load_plugin(string name) to load_plugin(string name, int version) (where version is currently hardcoded to 2, BTW).

Now if we have an incompatible change, we will bump the plugin version and it will be reflected in the RPM dependencies. This gets closer to the regular shared library versioning (except omitting the "compatible change" part, the second numeric component after .so).

Of course, nothing will save us from introducing an incompatibility and not bumping the version.

(Note to self: the code to change is findy2plugin in http://svn.opensuse.org/svn/yast/trunk/core/libycp/src/pathsearch.cc)
(Anonymous)
Jan. 18th, 2010 12:18 pm (UTC)
Re: plug-in versioning
I just love OpenID interoperability... --mvidner
( 3 comments — Leave a comment )