From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-66213-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id 5B5DC13877A
	for <garchives@archives.gentoo.org>; Sat, 14 Jun 2014 16:52:11 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id C9D1FE0B27;
	Sat, 14 Jun 2014 16:52:05 +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 E28D0E0AF7
	for <gentoo-dev@lists.gentoo.org>; Sat, 14 Jun 2014 16:52:04 +0000 (UTC)
Received: from rook (unknown [96.241.16.8])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: tetromino)
	by smtp.gentoo.org (Postfix) with ESMTPSA id D0F8A33F81E
	for <gentoo-dev@lists.gentoo.org>; Sat, 14 Jun 2014 16:52:03 +0000 (UTC)
Message-ID: <1402764656.16949.7.camel@rook>
Subject: Re: [gentoo-dev] Subslots: should they be bumped like SONAME or on
 any ABI changes?
From: Alexandre Rostovtsev <tetromino@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Date: Sat, 14 Jun 2014 12:50:56 -0400
In-Reply-To: <20140614164151.45afb5ca@pomiot.lan>
References: <20140614164151.45afb5ca@pomiot.lan>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-zWWs/K00OWora+R1QOPs"
X-Mailer: Evolution 3.12.3 
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
Mime-Version: 1.0
X-Archives-Salt: 6bc05bb6-1e96-44fb-a58b-8eeada8bffa5
X-Archives-Hash: 116f490a70dbe26f904e1f250b7ab6df


--=-zWWs/K00OWora+R1QOPs
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2014-06-14 at 16:41 +0200, Micha=C5=82 G=C3=B3rny wrote:
> Considering the libtool versioning, there are two kinds of library
> bumps relevant to us:
>=20
> 1) when ABI is altered in backwards-compatible way (so old stuff is not
> touched),
>=20
> 2) when ABI is altered in backwards-incompatible way.

The situation is more nuanced. I have also seen the following cases:

3) a package provides multiple libraries or entry points, and only some
of them have their ABI altered in a backwards-incompatible way.
Examples: xorg-server changes ABI for video drivers, but not for input
drivers; poppler changes ABI for libpoppler, but not libpoppler-glib.

4) a package alters a "private" ABI which matters for a small number of
closely-tied packages, but is transparent to normal users of the
library. Example: glib and gobject-introspection.

A solution to unnecessary rebuilds in these situations, as well as for
case (1), might be in the form of subslots as a key:value list, with
different users subscribing to be rebuilt for specific keys.

--=-zWWs/K00OWora+R1QOPs
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABAgAGBQJTnH1wAAoJEKRDAQ9PHUhgZMkP/08EyYhO6DnsPMXdGpOCglCA
45HchQKHWbWJj8Di8PgZrbsmxUyi9Bg3xBLuHtaA07JuGwhqRRwRL+jjzdbLXJjw
Vc/4a/c/fzG+C0IkU5nHK6V3o9UCpvv9qZGG0s45EymeeGO/D5T7ZhIVhVwit+gE
yAZefqa85vzILdVLDHG96PA2sqzfuudXmGgrJlD8p+POPv2bGbdDyCDWS9tak475
nQe5+q0p3YqPgy8vE3TFEpB61BJ1Gf+kNOww/7S61HlDJIEXcmDQJJe0mRzt7ZiD
05GF+GH7Y7LGFF5mK6Jx0cUqYPmJUXcuz0IRXMfAQDoJm1RAeYzNDDz57c3bYPTX
V6XZx2AzAOWkFITp3OWvxFq0TNdSo4t2VVewVk2lZMK7MMjsCIW8sFo/+YZBYhyo
IWNjUnuhm1rYmq3ecEbch/nw0wjb6L6JvG0y+2Cf7NiUoSyDjL3oBkBrTMhbmNIN
5eTaffu1gpmG31moaPwFSOa/SBc7bz5GoOkcZ/Iu87579IuaTHsHuSax7/hb8b9K
aeaUu2ka9UQe7dleAOcZ5RSxq0lZajLVocXLUuRgt1bAalDDwvDsxsXpiN0hZaA6
7cS6dlhdpkb7S4q1/7RwQ/O9iGSbRFyTGmINeqr+FIvZwYED21IuqEuUAJx2cb94
R7guTH4W9uwOk31kWP3i
=0gxX
-----END PGP SIGNATURE-----

--=-zWWs/K00OWora+R1QOPs--