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 338EF138010 for ; Fri, 7 Sep 2012 18:19:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 37C6021C040; Fri, 7 Sep 2012 18:18:39 +0000 (UTC) Received: from amun.cheops.ods.org (amun.cheops.ods.org [83.161.135.166]) by pigeon.gentoo.org (Postfix) with ESMTP id 1A69421C040 for ; Fri, 7 Sep 2012 18:17:21 +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 1TA37G-0007xw-5q for gentoo-dev@lists.gentoo.org; Fri, 07 Sep 2012 20:17:20 +0200 Date: Fri, 7 Sep 2012 20:17:17 +0200 From: Fabian Groffen To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: sub-slots (for EAPI 5) Message-ID: <20120907181717.GS5282@gentoo.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <1338845178.23212.1.camel@belkin4> <20120906090144.GS74867@gentoo.org> <5048A461.6080903@gentoo.org> <20120907171308.GP5282@gentoo.org> <504A341C.1080207@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="5TZBROn01cl7bgIF" Content-Disposition: inline In-Reply-To: <504A341C.1080207@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: 69d9176f-7432-4048-8281-98b8e3e5f0ea X-Archives-Hash: f42cea7883840df9e8406e4573e4ba87 --5TZBROn01cl7bgIF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 07-09-2012 13:51:24 -0400, Ian Stakenvicius wrote: > On 07/09/12 01:13 PM, Fabian Groffen wrote: > > 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. > >=20 > > I was interested in a (formal) specification, not a proof of > > concept. > >=20 >=20 > Ahh.. sorry, i figured the modified slot-operator spec that Ciaran > and Zac did was considered formal. Are you looking for a GLEP, then? > or... No, not a GLEP, per se. I'm trying to understand what sub-slot does and is. I think I'm starting to understand now. However, for this feature to be added to an EAPI, IMO it would be nice if there are resources that make it for most developers very clear how this feature should be used (and how not), and what kind of problems it can solve. I guess real-life examples, more extensively described than you did before, with exactly where it goes wrong, and how the situation is improved would help. > if you s/slot-deps/slot-operators/ , then yes i'm aware. to me, > "slot-deps" is something we got in (iirc) EAPI=3D2. The wiki calls it "Slot operator dependencies", which I abbreviate dto slot-deps. Sorry for the confusion. > >> [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) > >=20 > > 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. >=20 > If those (missing) functions are necessary then the either the full > slot, or the particular minimum package version, of libfnord would > need to be specified in the consumer. This isn't any different from > how things work now. Eh, no. Now it just always breaks when you perform a downgrade, and revdev-rebuild or @preserved-libs won't help you. I prefer that you give best practices how to use sub-slots to make Portage also able to do a recompile of bar when libfnord in the same SLOT gets downgraded. (Because minors are used for compatible changes -- additions -- to the ABI.) (And the recompile is preferably done against the headers of the downgraded version, but with the newer version's lib still around, such that if this is a vital binary such as Python, it will not break down -- however, this is most likely too much to ask.) > This is why, for the rebuild of bar-2.4 to be triggered on upgrade to > libfnord-3.5 the SLOT=3D var within libfnord-3.5.ebuild would need to > have something other than SLOT=3D"0/5", ie, SLOT=3D"0/5.12" Yeah, but can I also avoid bar-2.4 being recompiled when I install libfnord-3.5? It's not necessary, because the 5-ABI of libfnord is supposed to be backwards compatible. (At least that's the idea.) Like mentioned before, I DO want bar-2.4 to be recompiled if I have to downgrade libfnord to a version before the one I had installed when I compiled bar-2.4, though. > > Do you allow sub-slot to depend on e.g. USE-flags in use? Suppose=20 > > 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?=20 > > (I think SLOT is supposed to be metadata-static, but does the > > sub-slot part count to that?) >=20 > No, afaik slots (including sub-slots) can't be dynamic. Plus we > already have comprehensive use deps solutions so why would we need that? Because the ABI changes. But I guess you're right that we can safely ignore packages that screw it up badly enough here. Thanks --=20 Fabian Groffen Gentoo on a different level --5TZBROn01cl7bgIF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (Darwin) iEYEARECAAYFAlBKOi0ACgkQX3X2B8XHTokxEQCeL0vbp+ZkY26W1TmfKfdL+iR0 h3gAn3anPedkOxGkFc5/msRDQwHYWcZY =ATHm -----END PGP SIGNATURE----- --5TZBROn01cl7bgIF--