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 1Er4Lw-0006zx-TZ for garchives@archives.gentoo.org; Tue, 27 Dec 2005 02:14:17 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBR2DVkT020524; Tue, 27 Dec 2005 02:13:31 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 jBR2BTQh002261 for ; Tue, 27 Dec 2005 02:11:29 GMT Received: from [10.3.1.19] (helo=barracuda2.stayonline.net) by cubert.e-centre.net with esmtp (Exim 4.50) id 1Er4JC-0002BX-Cp for gentoo-dev@lists.gentoo.org; Mon, 26 Dec 2005 21:11:28 -0500 X-ASG-Debug-ID: 1135649485-23792-466-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 E4D3AA03CD for ; Mon, 26 Dec 2005 21:11:25 -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 jBR2BD5j017740 for ; Tue, 27 Dec 2005 02:11:13 GMT Date: Mon, 26 Dec 2005 18:11:24 -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: <20051227021124.GH5809@nightcrawler.e-centre.net> References: <43A235AD.6030604@leetworks.com> <200512262109.39704.carlo@gentoo.org> <20051227012908.GF5809@nightcrawler.e-centre.net> <200512270301.20576.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="vSsTm1kUtxIHoa7M" Content-Disposition: inline In-Reply-To: <200512270301.20576.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: 260f4657-a918-4032-87b8-2af32edd3224 X-Archives-Hash: d2bbb962dfd75821a9dfd6bd21e98810 --vSsTm1kUtxIHoa7M Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 27, 2005 at 03:01:13AM +0100, Carsten Lohrke wrote: > On Tuesday 27 December 2005 02:29, Brian Harring wrote: > > So... basically, your concern is with the resolver, not use/slot deps > > syntax. >=20 > I did not say that this would have anything to do with the syntax. Am I r= ight=20 > to extract from your words that we get rid of ~arch users complains about= =20 > up/downgrade cycles with Portage 2.1 as well, but have them confronted wi= th a=20 > proper error message!? :) Never said anything about 2.1 + resolver enhancements (no clue where=20 that one came from). Merely commenting on your raised issues about=20 use/slot deps. > > > - The dependencies we have are always >=3Dkde-libs/kde-x.y and when K= DE 4 > > > is due, we can change to =3Dkde-libs/kde-3.5* because everything else= won't > > > be supported anymore. So unless I miss something, kde-libs/kde:X is > > > superfluous. > > > > Missing something /me thinks. > > shouldn't really be specifying >=3Dkde-x.y; should be specifying the > > slotting. Do that, and you wouldn't have to go back and change it > > over to =3Dkde-libs/kde-3.5* ; you just mark the new kde-4 as a > > different slot. >=20 > Of course slot dependencies are cleaner. Just that they don't address a= =20 > practical problem with ebuilds buildable against multiple slotted ebuilds= of=20 > one packages, but the need to have them, their dependencies and all other= =20 > ebuilds depending on the latter (ones [sp?]) built against one and the sa= me=20 > ebuild ( In reality a set of ebuilds, named KDE X.Y). That sounds more like a failure of the ebuild's dep/rdep=20 specification, either that or your hinting at the need to lock down=20 the rdep's an ebuild was built against. Either way, still not totally following your complaint, thus an actual=20 example would help (easiest to assume I'm a moron, and start at that=20 level of explanation). ~harring --vSsTm1kUtxIHoa7M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDsKLMvdBxRoA3VU0RAhm/AJ4ytf9Bmh7SdgQ7xEBbpCZYZM5FcwCgyuXl cnYI7Wb2Sxy70CESQc7TnZg= =d7Cg -----END PGP SIGNATURE----- --vSsTm1kUtxIHoa7M-- -- gentoo-dev@gentoo.org mailing list