-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 14/06/14 10:41 AM, Michał Górny wrote: > 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. >
I vote that as primary policy/general practice, it only be bumped for (2) -- the primary purpose of subslot rebuilds is to allow portage to figure out the deptree order when a dependency upgrade is going to break a package that may or may not be emerged later. "break" is the key term here. If users want to re-emerge the rdeps of a package on upgrade they can certainly do so, but I don't see this as something we want to force on everybody just because we can... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlOccrEACgkQ2ugaI38ACPBu1AD+LNiTezb0nnGtGoVW4AHjAMk7 sMxoTYTvcYn2MLfYrrAA/iXLTPsTdGUSQcWnq40zz5yK09RljYMlI7f2bk5SlWIt =x/MD -----END PGP SIGNATURE-----
