From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1ScDGB-00042h-7Y for garchives@archives.gentoo.org; Wed, 06 Jun 2012 10:14:39 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A8AE3E056C; Wed, 6 Jun 2012 10:14:25 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 46B79E0484 for ; Wed, 6 Jun 2012 10:13:55 +0000 (UTC) Received: from [192.168.26.2] (ip98-164-193-252.oc.oc.cox.net [98.164.193.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 9FE861B4033 for ; Wed, 6 Jun 2012 10:13:54 +0000 (UTC) Message-ID: <4FCF2D5F.3080902@gentoo.org> Date: Wed, 06 Jun 2012 03:13:51 -0700 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120506 Thunderbird/12.0.1 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] About forcing rebuilds of other packages issue References: <1338845178.23212.1.camel@belkin4> <4FCDFF18.3080600@gentoo.org> <1338903062.21833.7.camel@belkin4> <4FCE913C.5060104@gentoo.org> <1338971313.2706.4.camel@belkin4> <4FCF2012.3040500@gentoo.org> <1338976106.2706.36.camel@belkin4> In-Reply-To: <1338976106.2706.36.camel@belkin4> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: ad01f23c-5994-4168-bc75-405089ce035b X-Archives-Hash: 11371a04c14ba566a96d1041a43bde82 On 06/06/2012 02:48 AM, Pacho Ramos wrote: > El mi=C3=A9, 06-06-2012 a las 02:17 -0700, Zac Medico escribi=C3=B3: >> On 06/06/2012 01:28 AM, Pacho Ramos wrote: >>> El mar, 05-06-2012 a las 16:07 -0700, Zac Medico escribi=C3=B3: >>>> The "SLOT operator" dependencies that Ciaran has been advocating are >>>> very close to a good solution. However, if we want it to work with >>>> unslotted packages, then we need to introduce a separate ABI_SLOT >>>> variable as discussed here: >>>> >>>> https://bugs.gentoo.org/show_bug.cgi?id=3D192319#c18 >>>> >>>> It's really no more difficult to do than "SLOT operator" dependencie= s, >>>> it's more flexible, and we can do it in EAPI 5. >>> >>> In that case, I obviously wouldn't have any problem with that approac= h >>> (it sound even better :)). Is there any place where I could get a bit >>> more documentation about how this "SLOT operator" way would work? For >>> example, how would work for rebuilding x11 drivers after updating xor= g >>> or rebuilding gobject-introspection after major glib update...=20 >> >> Whenever you have an ABI change, the developer doing the version bump >> needs to increment the SLOT (or ABI_SLOT if we use a separate variable= ) >> in the package. Packages that depend on the package with the ABI chang= e >> (reverse dependencies) append a :=3D operator to their dependency atom= s, >> indicating that they are locked to the ABI of the SLOT that they are >> built against. The package manager translates the :=3D operators into = a >> dependencies on specific SLOTs at build time, so that when you update >> your system next time, it can use this information to trigger rebuilds >> automatically when necessary. >=20 > That looks nice, only two notes: > - Looks like would be more sense on distinguish between "SLOT" and > ABI_SLOT, for example: > * dbus-glib would rdepend on glib:2 > * if glib:2 abi changes, we would pull a ABI_SLOT=3D"2.32" inside glib= -2 > ebuild > * dbus-glib rdepending on glib:=3D2 would get rebuilt > If we would use "SLOT" for all the cases, how would we handle it? I > mean, glib slot would be bumped to "2.32" and dbus-glib ebuilds updated > to rdepend on every new slot? Or would package managers distinct betwee= n > "versions" inside the same SLOT variable? For this situation, it seems like it's easier to have separate SLOT and ABI_SLOT entities. Maybe the dbus-glib dependency would be expressed as glib:2:=3D and the package manager would translate that to glib:2:2.32 at build time. So, the atom has separate SLOT and ABI_SLOT parts. > - What would occur with packages forced to use eapi0 due backwards > compat? We could probably deprecate eapis older than 5 to allow all the > tree be consistent with this rebuilds forcing, but no idea what to do > with system packages still needing to use eapi0 and maybe changing thei= r > ABI too :/ All EAPIs have SLOT, so at least the reverse dependencies on these system packages would be able to use SLOT operator deps. It's also conceivable that ABI_SLOT support could be retroactively added to older EAPIs. Obviously, the SLOT operator :=3D dependencies themselves can only be use= d in new EAPIs, so you won't be able to use them until you're willing to bump the EAPI of your package. --=20 Thanks, Zac