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 1EsK8m-0006Mu-LE for garchives@archives.gentoo.org; Fri, 30 Dec 2005 13:17:53 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBUDGjVe003507; Fri, 30 Dec 2005 13:16:45 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 jBUDDiIl005906 for ; Fri, 30 Dec 2005 13:13:45 GMT Received: from c83-251-211-193.bredband.comhem.se ([83.251.211.193]) by smtp.gentoo.org with esmtpa (Exim 4.54) id 1EsK4l-0007U7-PY for gentoo-dev@lists.gentoo.org; Fri, 30 Dec 2005 13:13:44 +0000 Subject: Re: [gentoo-dev] Multiple Repo Support From: "Spider (DmD Lj)" To: gentoo-dev@lists.gentoo.org In-Reply-To: <200512302149.24314.jstubbs@gentoo.org> References: <43A235AD.6030604@leetworks.com> <200512301035.41814.jstubbs@gentoo.org> <1135945051.2837.8.camel@Darkmere.darkmere> <200512302149.24314.jstubbs@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/UvdhnYv7JtzarYQ0coD" Organization: Gentoo Date: Fri, 30 Dec 2005 14:13:38 +0100 Message-Id: <1135948419.9003.4.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: bd57bd20-7c1a-4ec3-8848-ec1aeddda12a X-Archives-Hash: 5c928478c1d81714df6d040ee472e562 --=-/UvdhnYv7JtzarYQ0coD Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-12-30 at 21:49 +0900, Jason Stubbs wrote: > On Friday 30 December 2005 21:17, Spider (DmD Lj) wrote: > > > > No, what you suggested was that for the case of when you depend on a > > SLOT, then the tree is flattened. My point was for the generic case : > > > > DEPEND=3D">=3Dkde-base/kdelibs-3.0" (as many ebuilds look today) > > > > is then expanded to the current matching SLOT of kdelibs, so even if > > there -wasn't- a SLOT requirement beforehand, there is one afterwards. >=20 > Okay, I misinterpreted. Anyway, it looks like neither of our ideas will w= ork: >=20 > app-text/docbook-sgml/docbook-sgml-1.0.ebuild: >=20 > RDEPEND=3D"app-text/sgml-common app-text/openjade > >=3Dapp-text/docbook-dsssl-stylesheets-1.64 > >=3Dapp-text/docbook-sgml-utils-0.6.6 > ~app-text/docbook-sgml-dtd-3.0 > ~app-text/docbook-sgml-dtd-3.1 > ~app-text/docbook-sgml-dtd-4.0 > ~app-text/docbook-sgml-dtd-4.1" > docbook-sgml-dtd-3.0-r3.ebuild:SLOT=3D"3.0" > docbook-sgml-dtd-3.1-r3.ebuild:SLOT=3D"3.1" > docbook-sgml-dtd-4.0-r3.ebuild:SLOT=3D"4.0" > docbook-sgml-dtd-4.1-r3.ebuild:SLOT=3D"4.1" >=20 Hmm, however theese are the ~ atoms, I'm not quite sure how those are treated in the current tree, however in "my" proposal it would block against "requirement of same package with different SLOT. =20 However, since the ~ atoms are explicit and separate ( this depend tree could as well be called : app-text/docbook-sgml-dtd:3.0 app-text/docbook-sgml-dtd:3.1 app-text/docbook-sgml-dtd:4.0 app-text/docbook-sgml-dtd:4.1 Which, for some reason, should be supported : ) =20 Either by casing out appearances where multiple SLOTs are depended on by -one- package, or by saying that ~ is special-cased due to its stricter limitations, which would make it pass by the SLOT check. =20 ( no, its not an elegant solution, but it might work ;) //Spider --=20 begin .signature Tortured users / Laughing in pain See Microsoft KB Article Q265230 for more information. end --=-/UvdhnYv7JtzarYQ0coD 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) iD8DBQBDtTKCZS9CZTi033kRAr90AJ9k50356sG6o5Ba/OC1nlt6mJkHEQCeOC+r Z7LhrhWVIHZy2+gs1au80Tg= =hocc -----END PGP SIGNATURE----- --=-/UvdhnYv7JtzarYQ0coD-- -- gentoo-dev@gentoo.org mailing list