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 1EsNf9-0000Aa-LT for garchives@archives.gentoo.org; Fri, 30 Dec 2005 17:03:32 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBUH2kMx026864; Fri, 30 Dec 2005 17:02:46 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBUH0cf4008784 for ; Fri, 30 Dec 2005 17:00:39 GMT Received: from c83-251-211-193.bredband.comhem.se ([83.251.211.193]) by smtp.gentoo.org with esmtpa (Exim 4.54) id 1EsNcL-0002gI-J8 for gentoo-dev@lists.gentoo.org; Fri, 30 Dec 2005 17:00:38 +0000 Subject: Re: [gentoo-dev] Multiple Repo Support From: "Spider (DmD Lj)" To: gentoo-dev@lists.gentoo.org In-Reply-To: <200512302254.46585.jstubbs@gentoo.org> References: <43A235AD.6030604@leetworks.com> <200512302149.24314.jstubbs@gentoo.org> <1135948419.9003.4.camel@Darkmere.darkmere> <200512302254.46585.jstubbs@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-u+t/nHD4Qz+LaP4GWCmo" Organization: Gentoo Date: Fri, 30 Dec 2005 18:00:29 +0100 Message-Id: <1135962029.9034.1.camel@Darkmere.darkmere> 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 X-Mailer: Evolution 2.4.2.1 X-Archives-Salt: 731f16d3-29e7-473b-965f-2ccef5a652ec X-Archives-Hash: 7bdaa0aaa427d167ea36ab0df053acf2 --=-u+t/nHD4Qz+LaP4GWCmo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-12-30 at 22:54 +0900, Jason Stubbs wrote: >=20 >=20 > A still inelegant solution, but one that I could live with, is to > leave SLOT handling as it is now and to take Brian's syntax of > key:slot,slot using it specifically for the case where a set of > ebuilds must all use the same slot.=20 >=20 > Hence, rather than digikam and friends having "|| ( kdelibs:3.4 > kdelibs:3.5 )" each would have just "kdelibs:3.4,3.5". It still sounds > messy given the current redesign of atom handling, but it would seem > to offer a better chance of not being bug-ridden...=20 Hmm.. Do you mean this -after- expansion, or as hard-coded into the tree of ebuilds? If so, it's probably a no-go. Since the dep as stated in the tree doesn't even -want- to bind itself to a SLOT (can work with any 3.x version, is probably the most common criteria). And, I'm not sure just how this mangling would look when expanded in the installed package database, can you elaborate a bit? //Spider --=20 begin .signature Tortured users / Laughing in pain See Microsoft KB Article Q265230 for more information. end --=-u+t/nHD4Qz+LaP4GWCmo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBDtWetZS9CZTi033kRAgwJAKCI6b3weG6pH0XsH8v33LA88R33CgCfeMBf rKb8HDeNbu9YEH2QvVDPOWU= =jmVn -----END PGP SIGNATURE----- --=-u+t/nHD4Qz+LaP4GWCmo-- -- gentoo-dev@gentoo.org mailing list