From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 7C38813877A for ; Sat, 14 Jun 2014 14:42:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 573B2E097E; Sat, 14 Jun 2014 14:42:04 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 53C76E0932 for ; Sat, 14 Jun 2014 14:42:03 +0000 (UTC) Received: from pomiot.lan (static-81-219-255-132.devs.futuro.pl [81.219.255.132]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 8F56C33FE34; Sat, 14 Jun 2014 14:42:01 +0000 (UTC) Date: Sat, 14 Jun 2014 16:41:51 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: Subject: [gentoo-dev] Subslots: should they be bumped like SONAME or on any ABI changes? Message-ID: <20140614164151.45afb5ca@pomiot.lan> Organization: Gentoo X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/_o7dkME/E8BOLIGn76CxqOh"; protocol="application/pgp-signature" X-Archives-Salt: 66b7ce17-c122-4b9b-b473-bb7fb8721a9e X-Archives-Hash: 846efedbd615c3ae9ab15f4c44906cc5 --Sig_/_o7dkME/E8BOLIGn76CxqOh Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable 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=3D510780 --=20 Best regards, Micha=B3 G=F3rny --Sig_/_o7dkME/E8BOLIGn76CxqOh Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJTnF8zXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZO690P/0y4PXbMQ1nURfLf8UWdsQNB 6EUoh6QJ1afd8ZT4Lo8fjIdiroCO4h931aAf3ZWlXuXbiuGKQO1KunZHIHX6fh8Z tIhyjWep9MUHmN4kSoAfFgcSzYKTNBuG56GCm0O0Up67dF9zL4A3FIxKlVGjaQQ6 IsNItK5o7lZ4mGFTMLP2OmwtdmE0sxfx3LsQstwNGFX87Mbe29O7CX8Fafh4+H/u yunO1p2yx7uStzsLZyjIGu+exHM1nMkK/emgOafmTfRmU+KtI/CFvE7SKbKqeWZs 3IdTC6nc96iAOIhZGRoKhIADf/SEqv8OueM99+cwWcEdal66kZOpzMrmhhCW0gbU JB2Hxxyr80eL0W8eg9vnsAA3rq1zEMMPEtqLt+X8azLbec08YPbnGcZPeURlcA7D D57MqMF4ziyYX6V8mKm/HLrTNuZ7Ev8yLsyHBczwXX9wk8V+iQOgAg2Q0gYYA8KM 21/Y7KkfHKRphKfQP/UDCbz0vuwrsxOO51QOg0nT/ZOLPraFj0y7xWTew57o56y9 7t6AnIbbVZmOUm5wZ+G4vdLWwy8zMUiL5RKDCqqRpYx16sT15LY0kfd8DeklRvXE B4OVOTi2G4IKWy6T2NccjWK6CsF2/RmUY2utyGXpLGGBk9MFSM8fLW+8PSXTft8i EWen/azLxIjcyq5uU9H1 =nmQL -----END PGP SIGNATURE----- --Sig_/_o7dkME/E8BOLIGn76CxqOh--