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 <[EMAIL PROTECTED]> > > >
> > 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... > > I suggested this last Tuesday.. 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=">=kde-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. > > > I can smell sooo much breakage from this solution. Even though it could > > work : ) > > I'm not sure to interpret this as "yet another snide remark" or not so I'll > give you the benefit of the doubt and assume you're referring to sets of > ebuilds that require several slots. Before implementing the above, the tree > 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 >=kde-base/kdelibs-3:3.1 and >=kde-base/kdelibs-3:3.4 . 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 -- begin .signature Tortured users / Laughing in pain See Microsoft KB Article Q265230 for more information. end
signature.asc
Description: This is a digitally signed message part
