Applications and bundled libraries

Posted Mar 18, 2010 9:48 UTC (Thu) by jengelh (subscriber, #33263)
In reply to: Applications and bundled libraries by agl
Parent article: Applications and bundled libraries

>Having said that we do have a number of forks. Here's an unrepresentative selection of them covering some of the reasons:
>
>libevent: need new version for bugfixes
>icu: we need a more recent version than was even provided on Karmic.
>[and so on]

So what? If $distro ships libevent2-1.4.9 for example, there are two choices:
1. you need libevent.so.2-1.4.10: fine, make it a dependency of chromium and let the distro update their libevent2.
2. you need libevent.so.3-1.5.0: fine, make it a dependency of chromium and let the distro add a package libevent3.

sqlite: if upstream is not interested, rename it, and let the distro have a sqlite-google package created (this also requires that you make it use a different SONAME than the pristine sqlite), or, if it's API-compatible, have the distro replace the original sqlite/import your patch.

to post comments

Applications and bundled libraries

Posted Mar 18, 2010 15:04 UTC (Thu) by NAR (subscriber, #1313) [Link] (4 responses)

If $distro ships libevent2-1.4.9 for example, there are two choices:
1. you need libevent.so.2-1.4.10: fine, make it a dependency of chromium and let the distro update their libevent2.

What happens if libevent.so.2-1.4.10 breaks some other application? There are surprising number of applications that actually depend even on specific bugs being present in a library (because e.g. the bug was there years ago and they've implemented a workaround which will be broken by the proper fix)...

Applications and bundled libraries

Posted Mar 18, 2010 15:11 UTC (Thu) by jengelh (subscriber, #33263) [Link]

A responsible distro tries to coordinate one or more fixes being available to them and upstream, because ultimately, the distro will ship a newer version of the library at some point and the programs.
The world would probably have a lot more compile/runtime failures and churn if distros did not do what they are already doing.

Applications and bundled libraries

Posted Mar 18, 2010 15:28 UTC (Thu) by cortana (subscriber, #24596) [Link] (2 responses)

If a new release of a library alters behaviour in a backwards-incompatible way, then the SONAME
is bumped (that is, going from libevent.so.2 to libevent.so.3 in the example).

Applications and bundled libraries

Posted Mar 19, 2010 11:30 UTC (Fri) by smurf (subscriber, #17840) [Link] (1 responses)

Yeah, for major changes. For minor ones (like the aforementioned bug workarounds), symbol versioning is a much better choice.

Applications and bundled libraries

Posted Mar 19, 2010 11:36 UTC (Fri) by jengelh (subscriber, #33263) [Link]

Symbol versioning would not work in this case, I think, because as you recompile $broken_program (which can easily happen in things like rawhide/factory), you are linking it against $new_symbol.