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 1Eqyib-0006WG-1o for garchives@archives.gentoo.org; Mon, 26 Dec 2005 20:13: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 jBQKCOtO004452; Mon, 26 Dec 2005 20:12:24 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 jBQK9hhC020259 for ; Mon, 26 Dec 2005 20:09:44 GMT Received: from d134058.adsl.hansenet.de ([80.171.134.58] helo=iglu.bnet.local) by smtp.gentoo.org with esmtpa (Exim 4.54) id 1Eqyf8-0003fi-Nr for gentoo-dev@lists.gentoo.org; Mon, 26 Dec 2005 20:09:43 +0000 From: Carsten Lohrke To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Multiple Repo Support Date: Mon, 26 Dec 2005 21:09:31 +0100 User-Agent: KMail/1.9 References: <43A235AD.6030604@leetworks.com> <200512232230.15897.carlo@gentoo.org> <20051224010432.GF5796@nightcrawler.e-centre.net> In-Reply-To: <20051224010432.GF5796@nightcrawler.e-centre.net> 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; boundary="nextPart2561497.y2rL6Ij6Z5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512262109.39704.carlo@gentoo.org> X-Archives-Salt: a1bfb383-d3f4-41a0-8e96-937a38a93214 X-Archives-Hash: 873bce34118baf32d68bd8fd2b73b893 --nextPart2561497.y2rL6Ij6Z5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 24 December 2005 02:04, Brian Harring wrote: > dev-lang/python[tcltk] > ^^^ need that atom resolved with use flag tcltk enabled I think that's exactly what someone told me months ago. :) > >=3Dsys-apps/portage-2.0[sandbox,!build] > > ^^^ need >=3Dportage-2.0 merged with sandbox on, build off. I wonder if portage deals fine with subtle dependency incompatibilities, wh= en=20 one package has foo[!bar] and another one foo[bar] as dependency and spits= =20 out a reasonable error message to apply mutual blockers. > 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. This is the one I'm entirely not sure what it is good for. To me it looks m= ore=20 like a workaround for missing dependency ranges, but it won't solve any iss= ue=20 for KDE related packages.=20 =2D 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 superfluou= s. =2D What we need is that ebuilds build against KDE slot X force a rebuild o= f=20 those dependencies, which were against KDE slot Y as well as every other=20 installed ebuild depending on them. Right now my fugly slot_rebuild()=20 workaround lets the user do the job by hand. 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, that = we=20 need to consider another factor, later? :[]<>? Wouldn't it be better to hav= e=20 a extensible scheme, like e.g. $category/$ebuild[use:foo,!bar;slot:x,y] ? Carsten --nextPart2561497.y2rL6Ij6Z5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux) iD8DBQBDsE4DVwbzmvGLSW8RAg4TAJ9W1PYmtKd8QyWcTgAwWkjxwIMi4gCgiuZq DuS/MZzqljrJ+JirutVollk= =8XnN -----END PGP SIGNATURE----- --nextPart2561497.y2rL6Ij6Z5-- -- gentoo-dev@gentoo.org mailing list