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 491F8138010 for ; Fri, 7 Sep 2012 17:14:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7931C21C002; Fri, 7 Sep 2012 17:14:22 +0000 (UTC) Received: from amun.cheops.ods.org (amun.cheops.ods.org [83.161.135.166]) by pigeon.gentoo.org (Postfix) with ESMTP id A7D0CE068F for ; Fri, 7 Sep 2012 17:13:13 +0000 (UTC) Received: from nut.cheops.ods.org ([2001:888:1022:0:ca2a:14ff:fe35:7a00] helo=gentoo.org) by amun.cheops.ods.org with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TA27C-0007bT-0Q for gentoo-dev@lists.gentoo.org; Fri, 07 Sep 2012 19:13:12 +0200 Date: Fri, 7 Sep 2012 19:13:08 +0200 From: Fabian Groffen To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue Message-ID: <20120907171308.GP5282@gentoo.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <1338845178.23212.1.camel@belkin4> <20120906090144.GS74867@gentoo.org> <5048A461.6080903@gentoo.org> 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-sha1; protocol="application/pgp-signature"; boundary="y/A/1bIHS6WQt0eA" Content-Disposition: inline In-Reply-To: <5048A461.6080903@gentoo.org> User-Agent: Mutt/1.5.21 (Darwin 11.4.0, VIM - Vi IMproved 7.3) Organization: Gentoo Foundation, Inc. X-Content-Scanned: by amun.cheops.ods.org (Exim Exiscan) using SpamAssassin and ClamAV X-Archives-Salt: faacea5d-c45c-42ab-9039-aae49d3403a3 X-Archives-Hash: 6c6159bc15119e968b2ba908fb779d06 --y/A/1bIHS6WQt0eA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 06-09-2012 09:25:53 -0400, Ian Stakenvicius wrote: > #1 - there is both a specification, and an initial implementation, AND > a fork of the tree that is kept semi-up-to-date on my dev overlay. I was interested in a (formal) specification, not a proof of concept. > #2 - related to your question about what the proposal solves -- in my > opinion, the biggest thing the proposal solves is the case where we > want the ability to use SLOTs in the tree to manage and track > dependency changes (ie, when an API or ABI has changed), but NOT allow > multiple versions of a package to be installed at the same time. > Further to this, it allows PMs to determine what needs to be rebuilt > due to the old (no longer existing) dep being supported prior to said > dep actually being removed. =2E.. > sub-slots is the 'some-identifier' part of ${SLOT}/${some-identifier}. > It doesn't have to replate to ${PV} at all, and generally shouldn't. > More likely it should relate to the ${major}.${minor} in the main > library's SONAME. For non-libtool dependencies some other form of id > is used, ie for perl I used the major.minor from $PV. > EAPI=3D"4-slot-deps" is new to me; the implementation i've been testing You refer to it lateron, so it seems to me you're unaware your sub-slots and slot-deps are made as one commit [1]. > is EAPI=3D"4-slot-abi" which is sub-slots and slot operators. This is > the spec that was written and proposed for EAPI=3D5 and so this is what > i'll use to describe the above. both are proposed for EAPI=3D5 [2] > First, assuming currently libfnord is SLOT=3D0, and that there are no > ABI/API breakages on libfnord-2 through libfnord-3.5, I would just use > the ${major} version from the SONAME for the sub-slot. IE: >=20 > libfnord-1:SLOT=3D"0/3" > libfnord-2:SLOT=3D"0/5" > libfnord-2.1:SLOT=3D"0/5" > ... > libfnord-3.5:SLOT=3D"0/5" >=20 > And then, assuming that foo and bar both link in the usual way, IE > they link against libfnord.so.3 instead of just libfnord.so , they SONAME indeed refers to the versioned lib, although linking is of course done against libfnord.so (-lfnord). > both would RDEPEND as follows: >=20 > RDEPEND=3D"app-cat/libfnord:=3D" This is "Slot operator dependencies" syntax. > > (numeric indicators added): [1]What if libfnord-2.1 or libfnord-3.5 > > would be masked due to some problem not noticed prior to stabling > > that makes it useless for many users. [2]bar-2.4 during configure > > checks for a new function in libfnord-3.5 and uses it if available, > > or uses an alternative code-path instead. [3]libfnord-2.1-r5 fixes > > a crash in some function of the library. (Note: this whole > > example/question sounds like an ebuild-quiz question that any dev > > should be able to answer then.) > >=20 > > What would be the advantage of sub-slot here, assuming the > > versioning of the libraries follows ABI versioning rules defined by > > e.g. libtool. >=20 > [1] No advantage as sub-slots wouldn't relate to this, UNLESS the > masking would then remove -all- SLOT=3D"0/5" versions from the tree. In > that case, the old SLOT=3D"0/3" provider would be the 'upgrade' path and > so 'foo' and 'bar' would be triggered for rebuild (since the lib they > were linked to would be disappearing during emerge -uDN) So your example SLOTs are wrong, and should have included the minor (always!?!) since downgrading a lib that goes back to an older minor means functions no longer exist, thus a consumer can potentially break. > [2] In this case, the new ABI/API offering in libfnord-3.5 would need > to be addressed in the SLOT, ie, SLOT=3D"0/5.12". As such when > libfnord-3.5 would be upgraded then bar-2.4 (if it was already emerged > of course) would be triggered for rebuild. 'foo' would afaik also be > triggered for rebuild, though, as (at present) there isn't a way to > match partial sub-slots (or sub-sub-slots, as it were) via the slot > operators :=3D and :*. So you basically say: this is slot-dep, you store that bar-2.4 uses libfnord-2.1. > [3] No advantage, as linking would be consistent. Sub-slots wouldn't > be needed in this case, and afaict updating libfnord-2.1 to > libfnord-2.1-r5 wouldn't trigger revdep-rebuild or require any > additional mediation anyways. Yes. > Hope this helps clear things up.. I think I understand why ciaramn suggested the use of / iso SUB_SLOT (or something like that) here. Could you give an example where implicit ${PV} as sub-slot would not do what you need? Do you allow sub-slot to depend on e.g. USE-flags in use? Suppose libfnord has a USE-flag cow that adds special cow interfaces to the ABI/API. Would SLOT=3D"X/${PV}$(use cow && echo -- -cow)" work? (I think SLOT is supposed to be metadata-static, but does the sub-slot part count to that?) [1] http://git.overlays.gentoo.org/gitweb/?p=3Dproj/portage.git;a=3Dcommit;= h=3De4ba8f36e6a4624f4fec61c7ce8bed0e3bd2fa01 [2] http://wiki.gentoo.org/wiki/EAPI_5_tentative_features --=20 Fabian Groffen Gentoo on a different level --y/A/1bIHS6WQt0eA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (Darwin) iEYEARECAAYFAlBKKyQACgkQX3X2B8XHTomtJQCfbVoee/cKjkMcGWlQ01hvkIPT rxIAn1w90DjQOpAznu6nh0g1CLgPKyxr =PGFc -----END PGP SIGNATURE----- --y/A/1bIHS6WQt0eA--