Re: [gentoo-dev] Multiple Repo Support

["Spider (DmD Lj)" <spider@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2626 bytes --]

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 <carlo@gentoo.org>
> > >

> > 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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]