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 1EsJF6-00000K-2R for garchives@archives.gentoo.org; Fri, 30 Dec 2005 12:20:20 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBUCJWLH007193; Fri, 30 Dec 2005 12:19:32 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 jBUCHYfQ008438 for ; Fri, 30 Dec 2005 12:17:34 GMT Received: from c83-251-211-193.bredband.comhem.se ([83.251.211.193]) by smtp.gentoo.org with esmtpa (Exim 4.54) id 1EsJCP-00008V-P7 for gentoo-dev@lists.gentoo.org; Fri, 30 Dec 2005 12:17:34 +0000 Subject: Re: [gentoo-dev] Multiple Repo Support From: "Spider (DmD Lj)" To: gentoo-dev@lists.gentoo.org In-Reply-To: <200512301035.41814.jstubbs@gentoo.org> References: <43A235AD.6030604@leetworks.com> <20051227190619.3c824d0d@snowdrop.home> <1135874128.2170.6.camel@Darkmere.darkmere> <200512301035.41814.jstubbs@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-J9ACXRM4FmZ77CCZcjt8" Organization: Gentoo Date: Fri, 30 Dec 2005 13:17:31 +0100 Message-Id: <1135945051.2837.8.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: c4c1b89a-72c4-4b30-a285-621b023fca29 X-Archives-Hash: bf63a8e193428f3f0946985d7419b589 --=-J9ACXRM4FmZ77CCZcjt8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-12-30 at 10:35 +0900, Jason Stubbs wrote: > On Friday 30 December 2005 01:35, Spider (DmD Lj) wrote: > > On Tue, 2005-12-27 at 19:06 +0000, Ciaran McCreesh wrote: > > > On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke > > > > > Thats actually viable. For -installed- ebuilds, we simply unpack all > > RDEPEND logic, remove all use flags ( stored, but the use logic is > > removed from the RDEPEND since its already resolved, doesn't need to be > > there. The binary is static already ) > > > > Then check vs. the installed SLOT of all RDEPEND packages, and lock our > > current deptree to the package of that SLOT... >=20 > I suggested this last Tuesday..=20 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) =20 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 > > I can smell sooo much breakage from this solution. Even though it could > > work : ) >=20 > I'm not sure to interpret this as "yet another snide remark" or not so I'= ll=20 > give you the benefit of the doubt and assume you're referring to sets of=20 > ebuilds that require several slots. Before implementing the above, the tr= ee=20 > will be checked for any cases where the above idea will fail. And, I know you're bitter and tangy about uncalled for remarks about portage development, however, by looking at my assumption of suddenly starting to tie packages to SLOT's, yes, I predict massive levels of interesting bugs to start appear, where we get obscure depend-cases of things suddenly causing a rebuild of packages deep inside the tree, which then suddenly spark rebuilds against others in the tree upwards, due to depend atoms flicking the SLOT of one of the bottom libs that are depended upon. Since I also suggested (or tried to convey) the requirement that for a single depgraph ( the graph to package foo) there may never be SLOT collisions for a single lib... So the whole mapped out tree may not, never, contain both >=3Dkde-base/kdelibs-3:3.1 and >=3Dkde-base/kdelibs-3:3.4 .=20 As its the only viable means I see of solving such dependencies, it also seems to be quite prone of breakage. To simply lock down SLOT depends would propbably not cause as much problems, however. //Spider --=20 begin .signature Tortured users / Laughing in pain See Microsoft KB Article Q265230 for more information. end --=-J9ACXRM4FmZ77CCZcjt8 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) iD8DBQBDtSVbZS9CZTi033kRAoQkAJ99jsXaplW7EDIHexvpFF5SnkpeGgCgitjU imkakzR+TOV17/YAMnpehT8= =jKL/ -----END PGP SIGNATURE----- --=-J9ACXRM4FmZ77CCZcjt8-- -- gentoo-dev@gentoo.org mailing list