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.67) (envelope-from ) id 1IDhtO-0005Wm-9A for garchives@archives.gentoo.org; Wed, 25 Jul 2007 14:31:10 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l6PET65r007375; Wed, 25 Jul 2007 14:29:06 GMT Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l6PEPkHC002273 for ; Wed, 25 Jul 2007 14:25:46 GMT Received: by py-out-1112.google.com with SMTP id d32so488150pye for ; Wed, 25 Jul 2007 07:25:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=oG0IvIbcYe03l7pnB/fUka/VJ2Hy1HEIKkNyijy1SXWo4QarNQqIdJkKTS2jP89ueb8lr2p/0jptxT7NZE6IVt4N4enWb6WBFxLVM5lQAh4LBkbrlBygDuIeahzvI7BUSQpty2aGi1q5WST9obqvHrnWOZERFYXOIeF3pqctGo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=DGcBg+0RaYL7itwGPWDAQaA+EICoNgrSkZQhBuU1OR/ZhlZ+L5ht3VmB07Dzcvy8cAJ2BJANy/ARhG9v3i5nKczu3JT6tcTPO+m7bH2wAR11vrIPnxaRlxzZ/QMm8fz2PH8qZr01a+EqXtp/6V5n+D6I42JkoyQK60s/ik5CTlE= Received: by 10.141.3.10 with SMTP id f10mr207358rvi.1185373542262; Wed, 25 Jul 2007 07:25:42 -0700 (PDT) Received: from seldon ( [71.141.141.124]) by mx.google.com with ESMTPS id k41sm1364766rvb.2007.07.25.07.25.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jul 2007 07:25:40 -0700 (PDT) Date: Wed, 25 Jul 2007 07:25:09 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] New PDEPEND behaviour. Message-ID: <20070725142509.GB17517@seldon> References: <200707251408.41171.peper@gentoo.org> <200707251452.02821.carlo@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="zx4FCpZtqtKETZ7O" Content-Disposition: inline In-Reply-To: <200707251452.02821.carlo@gentoo.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Archives-Salt: 3b1bbe20-ff6e-42f0-8700-2236f75edfbd X-Archives-Hash: 60fd68be11b89d908339257b7ecb9945 --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2007 at 02:51:55PM +0200, Carsten Lohrke wrote: > On Mittwoch, 25. Juli 2007, Piotr Jaroszy=C5=84ski wrote: > > As a result of bug #180045 PDEPENDs can be now merged even before the > > package that pulls them. Zmedico says that's intended behaviour >=20 > Well, then what our Portage devs think the intended behaviour should be i= s a=20 > bug. E.g. in the case the bug refers to, we rely on Portage building =20 > kdnssd-avahi after kdelibs (otherwise it simply would fail), but before a= ny=20 > other ebuild that might need kdnssd-avahi. I suggest you in the future check out what actually was changed, and=20 do some testing- both the original poster, and yourself are missing=20 what is occuring here (if it's any consolation, I missed the real=20 cause of 186517 initially too :). The portage change is to shift the=20 placement of PDEPENDed nodes as early as possible- specifically to=20 fix cases where deps are a bit screwed up (like 180045,=20 kdnssd-avahi/kdelibs). Note I said 'shift'. It tries to place it earlier in the graph, while=20 *still* maintaining the constraints of kdnssd-avahi- namely the=20 kdelibs dependency. Via that dep, kdnssd-avahi *requires* kdelibs to be installed first,=20 and portage honors that- it just now tries to get kdnssd-avahi merged=20 as soon as possible after kdelibs due to their PDEPEND relationship=20 (try it if in doubt, it lineralizes it properly). The cases where it doesn't, are when the constraints are already=20 satisfied- kdelibs already is merged, basically. There is a change in=20 placement there, but considering the data involved, wouldn't label it=20 a regression- same issue can, and does occur in multiple other ways. > And I'm pretty sure nearly=20 > everyone using PDEPEND in his ebuilds relies on Portage building the PDEP= END=20 > not before the ebuild, which lists it. No one has relied on that in my experience. They've relied on PDEPEND=20 being satisfied, but not required to be satisfied by the time the=20 PDEPENDer is considered 'satisfied' buildplan wise. I strongly suspect folks echoing that sentiment are missing that a=20 PDEPEND'ed nodes' DEPEND/RDEPEND *must* be satisfied prior to it being=20 merged, and are missing what PDEPEND means to the resolver. > > We need to update docs or harass zmedico to force PDEPEND to be pulled = as > > soon as possible but not before the pkg that pulls it. >=20 > The latter. Former. The ebuild manpage is a bit loose in it's description of what=20 PDEPEND does. As cardoe commented, the flaw that folks are hitting in 186517 is a=20 data flaw (the data is bad); it's not a flaw in the resolver=20 behaviour. Feed it bad data, it's going to do stupid things basically :) ~harring --zx4FCpZtqtKETZ7O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGp11EsiLx3HvNzgcRAgcqAKCQil8yq+ZoL4xoD/cBGouhjUyCpgCbB/nE jSCaSp31bbMubCpFMD4aJDU= =U1fb -----END PGP SIGNATURE----- --zx4FCpZtqtKETZ7O-- -- gentoo-dev@gentoo.org mailing list