El sáb, 14-06-2014 a las 16:41 +0200, Michał Górny escribió: > Hi, > > Some time ago we've got bug #510780 [1] asking us to bump subslot > on LLVM even though the new version was ABI-compatible with previous > one. It was because it introduced new APIs which applications could > make use of. Since I believe this is a wider issue, I would like to > know the opinion of our community about this. > > More specifically: do we want subslots to change only when backwards- > incompatible ABI changes are done -- alike SONAME -- or whenever any > ABI change is done? The problem seems a bit complex. > > Considering the libtool versioning, there are two kinds of library > bumps relevant to us: > > 1) when ABI is altered in backwards-compatible way (so old stuff is not > touched), > > 2) when ABI is altered in backwards-incompatible way. > > Option 1) corresponds to bumping minor libtool version, option 2) to > bumping SONAME. I think most of the packages follow SONAME in subslots > and therefore care only about 2). > > If we decide to keep bumping subslots only when SONAME changes, this > has two implications: > > a) new features introduced libraries are not used by packages built > prior to upgrading the library, > > b) packages built after upgrading the library may be broken when it is > downgraded (if they use the newer ABI). > > I think a) is not *that* a big deal since usually new ABIs involve new > APIs, and those involve code changes in the reverse dependency. Then we > can usually assume that the new version of reverse dependency will be > added (and therefore upgraded to) after the library in question. > > I have no strong opinion about b). This is a known issue with SONAMEs, > and I'm not sure if we really support people downgrading. It is worth > noting, however, that sometimes we ourselves force downgrades due to > issues with new versions. > > If we decide to bump subslots to match major+minor ABI version, we > force the reverse dependencies to always use the ABI corresponding to > installed library version. However, this means that we force much more > rebuilds than necessary. > > For example, glib-2 often introduces new APIs while packages obviously > don't use them immediately or at all. We will be forcing rebuild of > every reverse dependency at glib-2 upgrade, while the user will most > likely need to wait for another version bump (and rebuild) to get > the new glib-2 features used. > > What do you think? > > [1]:https://bugs.gentoo.org/show_bug.cgi?id=510780 >
I would opt for forcing rebuilds only when necessary, I mean, when not rebuilding them will cause issues. If people want to force packages to use latest glib-2 (for example), I guess they can do that "manually" (as the case of people rebuilding everything on every major gcc update)
