| 1 |
On Sat, 2014-06-14 at 16:41 +0200, Michał Górny wrote: |
| 2 |
> Considering the libtool versioning, there are two kinds of library |
| 3 |
> bumps relevant to us: |
| 4 |
> |
| 5 |
> 1) when ABI is altered in backwards-compatible way (so old stuff is not |
| 6 |
> touched), |
| 7 |
> |
| 8 |
> 2) when ABI is altered in backwards-incompatible way. |
| 9 |
|
| 10 |
The situation is more nuanced. I have also seen the following cases: |
| 11 |
|
| 12 |
3) a package provides multiple libraries or entry points, and only some |
| 13 |
of them have their ABI altered in a backwards-incompatible way. |
| 14 |
Examples: xorg-server changes ABI for video drivers, but not for input |
| 15 |
drivers; poppler changes ABI for libpoppler, but not libpoppler-glib. |
| 16 |
|
| 17 |
4) a package alters a "private" ABI which matters for a small number of |
| 18 |
closely-tied packages, but is transparent to normal users of the |
| 19 |
library. Example: glib and gobject-introspection. |
| 20 |
|
| 21 |
A solution to unnecessary rebuilds in these situations, as well as for |
| 22 |
case (1), might be in the form of subslots as a key:value list, with |
| 23 |
different users subscribing to be rebuilt for specific keys. |
Archives