From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1GQNHC-0004yg-Kf for garchives@archives.gentoo.org; Thu, 21 Sep 2006 12:03:35 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k8LC2ECM023591; Thu, 21 Sep 2006 12:02:14 GMT Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.200.81]) by robin.gentoo.org (8.13.8/8.13.6) with ESMTP id k8LBxKll000230 for ; Thu, 21 Sep 2006 11:59:21 GMT Received: from seldon (c-24-21-135-117.hsd1.or.comcast.net[24.21.135.117]) by comcast.net (sccrmhc11) with SMTP id <2006092111591801100afgtke>; Thu, 21 Sep 2006 11:59:18 +0000 Date: Thu, 21 Sep 2006 04:59:17 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC about another *DEPEND variable Message-ID: <20060921115916.GB30105@seldon> References: <45126B07.6030403@gentoo.org> <451279D3.9020605@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@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="R3G7APHDIzY6R/pk" Content-Disposition: inline In-Reply-To: <451279D3.9020605@gentoo.org> User-Agent: Mutt/1.5.11 X-Archives-Salt: fdc610c9-7ef1-4f10-baaf-4867e173c707 X-Archives-Hash: 54f544eb917852ce83d6472cc51a2234 --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 21, 2006 at 01:38:59PM +0200, Luca Barbato wrote: > Alin Nastac wrote: > >I reckon this could be solved by yet another *DEPEND variable. The only > >atoms accepted by this variable would be "CATEGORY/PN". Every time when > >a package gets updated from PV1 to PV2 (distinct versions, revisions > >will not count), portage will automatically re-emerge those packages > >that depend on it. > > > >Thoughts? > > >=20 > It would require revdep resolution on emerge... how painful would be? Off the top of my head, adding revdeps (period) for unmerge=20 functionality (fex) is the harder part; slipping something of this=20 sort in is just a logic tweak. The problem with this proposal however is that it's attempting=20 automatic revdep based off of version; _any_ non-rev version bump is=20 way too rebuild happy. Proposal I was pushing a while back was addition of a metadata key;=20 it's not exactly .so version, but pretty close- a _manually_=20 maintained counter var in the ebuild that represents the abi=20 compatibility for that packages versions. Example would be openssl-0.9.7, you stick BINCOMPAT=3D0.9.7 in it,=20 in openssl-0.9.8, you stick BINCOMPAT=3D0.9.8 in it, for a replace op=20 the resolver sees that it's breaking compatibility and knows to=20 rebuild any revdeps. Why have the explicit var? Because 0.9.7a through 0.9.7c may all be=20 compatible, but 0.9.7d isn't. If you force an automatic algo that=20 tries to (effectively) guess, you get a lot of rebuilds through a,b,c,=20 end result being folks likely update less because it becomes a bigger=20 pain in the ass. There is one flaw with this though; packages can provide both=20 libraries _and_ binaries. Our dependencies don't represent whether=20 the dep is actual linkage, or just commandline consuming, so (using=20 the openssl example) any package that invokes openssl via the=20 commandline to do a few simple chksum ops gets rebuilt, despite the=20 fact it wasn't affected by linkage change ups. So... short version, at least what jstubbs/marius/myself hashed out in=20 irc a long while back, need binding dependencies and actual tracking=20 of the lib breakage in the metadata. Alternative to shoving an extra key in would be extending slot rules,=20 but that can be somewhat ugly. My 2 cents, for what its worth. ~harring --R3G7APHDIzY6R/pk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFEn6UsiLx3HvNzgcRAuR8AKCO5oU+J19o4YFSjEw5S59B2aP+CgCfamxZ pwZ0bW1dyamqSVTnMwifi1A= =kr3E -----END PGP SIGNATURE----- --R3G7APHDIzY6R/pk-- -- gentoo-dev@gentoo.org mailing list