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.54) id 1Er3id-0004Sl-8W for garchives@archives.gentoo.org; Tue, 27 Dec 2005 01:33:39 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBR1W19b020017; Tue, 27 Dec 2005 01:32:01 GMT Received: from cubert.e-centre.net (morbo.e-centre.net [66.154.82.3]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBR1TAod025064 for ; Tue, 27 Dec 2005 01:29:11 GMT Received: from [10.3.1.19] (helo=barracuda2.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1Er3eI-00075i-Ko for gentoo-dev@lists.gentoo.org; Mon, 26 Dec 2005 20:29:10 -0500 X-ASG-Debug-ID: 1135646949-15358-983-0 X-Barracuda-URL: http://10.3.1.19:8000/cgi-bin/mark.cgi Received: from et-pdx-2.site.stayonline.net (unknown [65.200.64.131]) by barracuda2.stayonline.net (Spam Firewall) with ESMTP id 11544A7535 for ; Mon, 26 Dec 2005 20:29:09 -0500 (EST) Received: from nightcrawler ([172.16.1.202]) by et-pdx-2.site.stayonline.net (8.12.6/8.12.6) with ESMTP id jBR1Sv5j013487 for ; Tue, 27 Dec 2005 01:28:57 GMT Date: Mon, 26 Dec 2005 17:29:09 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org X-ASG-Orig-Subj: Re: [gentoo-dev] Multiple Repo Support Subject: Re: [gentoo-dev] Multiple Repo Support Message-ID: <20051227012908.GF5809@nightcrawler.e-centre.net> References: <43A235AD.6030604@leetworks.com> <200512232230.15897.carlo@gentoo.org> <20051224010432.GF5796@nightcrawler.e-centre.net> <200512262109.39704.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="ryJZkp9/svQ58syV" Content-Disposition: inline In-Reply-To: <200512262109.39704.carlo@gentoo.org> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by Barracuda Spam Firewall at stayonline.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=4.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.6644 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Archives-Salt: 9ae6fa8c-2c62-4f58-903a-e067eef4de0f X-Archives-Hash: 69a37b9f941869bec6c4902e4f85f1ec --ryJZkp9/svQ58syV Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 26, 2005 at 09:09:31PM +0100, Carsten Lohrke wrote: > On Saturday 24 December 2005 02:04, Brian Harring wrote: > > dev-lang/python[tcltk] > > ^^^ need that atom resolved with use flag tcltk enabled >=20 > I think that's exactly what someone told me months ago. :) >=20 > > >=3Dsys-apps/portage-2.0[sandbox,!build] > > > > ^^^ need >=3Dportage-2.0 merged with sandbox on, build off. >=20 > I wonder if portage deals fine with subtle dependency incompatibilities, = when=20 > one package has foo[!bar] and another one foo[bar] as dependency and spit= s=20 > out a reasonable error message to apply mutual blockers. Actually, you just hit upon one of the main reasons use/slot deps=20 have taken so damn long. Jason can state it better, but our resolver basically chooses a single=20 path when doing the resolution; if that resolution turns out to be an=20 issue during later resolution steps, existing resolver doesn't back=20 track and choose a different (valid) path.=20 Note the up/down cycling bugs. Guess how that comes about? use/slot deps is a combination of depset extension (plus any code that=20 deals with depset), and resolver extension so it handles the extension=20 of depset properly- namely, getting issues from above handled, trying=20 to dig it's way out of use cycles that aren't hard deps, etc. So... basically, your concern is with the resolver, not use/slot deps=20 syntax. > > kde-libs/kde:3 > > ^^^ need any kde, with slotting enabled. > > > > kde-libs/kde:3,4 > > ^^^ need any kde, slotting 3 or 4. > > > > Combination? Not set in stone afaik, the implementation I have > > sitting in saviour doesn't care about the ordering however. >=20 > This is the one I'm entirely not sure what it is good for. To me it looks= more=20 > like a workaround for missing dependency ranges, but it won't solve any i= ssue=20 > for KDE related packages.=20 What are dep ranges? It's the intersection of any version set's=20 specified by common cat/pkgs. In other words, instead of just=20 processing atom by atom, grab the depends, collapse them down into=20 cp->version restrictions, _then_ do the search. The issue you're=20 pointing at isn't use/slot dep based, it's resolver based (again). ;) > - The dependencies we have are always >=3Dkde-libs/kde-x.y and when KDE 4= is=20 > due, we can change to =3Dkde-libs/kde-3.5* because everything else won't = be=20 > supported anymore. So unless I miss something, kde-libs/kde:X is superflu= ous. Missing something /me thinks. shouldn't really be specifying >=3Dkde-x.y; should be specifying the=20 slotting. Do that, and you wouldn't have to go back and change it=20 over to =3Dkde-libs/kde-3.5* ; you just mark the new kde-4 as a=20 different slot. Basically... it's how it *should* be done from the get go, rather then=20 going back and fixing things via tweaking the scary eclass y'all have. :) > As a general remark I'd like to know if and how this enhanced dependency= =20 > syntax is ordered. :[], []: or is both allowed!? What if we find out, tha= t we=20 > need to consider another factor, later? :[]<>? Like I stated in a previous email, the ordering isn't specified- right=20 now we can split upon [] matches to handle it regardless of ordering,=20 although I'd think some form of ordering would be wise... ~harring --ryJZkp9/svQ58syV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDsJjkvdBxRoA3VU0RAu3jAKDO48pyYO4YkNL4YGo+bc2dnLgABQCg7xLP qErm7ehOpbstWXyApdPRSj0= =tgYa -----END PGP SIGNATURE----- --ryJZkp9/svQ58syV-- -- gentoo-dev@gentoo.org mailing list