1 |
On Fri, 2005-12-30 at 10:35 +0900, Jason Stubbs wrote: |
2 |
> On Friday 30 December 2005 01:35, Spider (DmD Lj) wrote: |
3 |
> > On Tue, 2005-12-27 at 19:06 +0000, Ciaran McCreesh wrote: |
4 |
> > > On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke <carlo@g.o> |
5 |
> > > |
6 |
|
7 |
> > Thats actually viable. For -installed- ebuilds, we simply unpack all |
8 |
> > RDEPEND logic, remove all use flags ( stored, but the use logic is |
9 |
> > removed from the RDEPEND since its already resolved, doesn't need to be |
10 |
> > there. The binary is static already ) |
11 |
> > |
12 |
> > Then check vs. the installed SLOT of all RDEPEND packages, and lock our |
13 |
> > current deptree to the package of that SLOT... |
14 |
> |
15 |
> I suggested this last Tuesday.. |
16 |
|
17 |
No, what you suggested was that for the case of when you depend on a |
18 |
SLOT, then the tree is flattened. My point was for the generic case : |
19 |
|
20 |
DEPEND=">=kde-base/kdelibs-3.0" (as many ebuilds look today) |
21 |
|
22 |
is then expanded to the current matching SLOT of kdelibs, so even if |
23 |
there -wasn't- a SLOT requirement beforehand, there is one afterwards. |
24 |
> |
25 |
> > I can smell sooo much breakage from this solution. Even though it could |
26 |
> > work : ) |
27 |
> |
28 |
> I'm not sure to interpret this as "yet another snide remark" or not so I'll |
29 |
> give you the benefit of the doubt and assume you're referring to sets of |
30 |
> ebuilds that require several slots. Before implementing the above, the tree |
31 |
> will be checked for any cases where the above idea will fail. |
32 |
|
33 |
|
34 |
And, I know you're bitter and tangy about uncalled for remarks about |
35 |
portage development, however, by looking at my assumption of suddenly |
36 |
starting to tie packages to SLOT's, yes, I predict massive levels of |
37 |
interesting bugs to start appear, where we get obscure depend-cases of |
38 |
things suddenly causing a rebuild of packages deep inside the tree, |
39 |
which then suddenly spark rebuilds against others in the tree upwards, |
40 |
due to depend atoms flicking the SLOT of one of the bottom libs that are |
41 |
depended upon. |
42 |
|
43 |
|
44 |
Since I also suggested (or tried to convey) the requirement that for a |
45 |
single depgraph ( the graph to package foo) there may never be SLOT |
46 |
collisions for a single lib... So the whole mapped out tree may not, |
47 |
never, contain both >=kde-base/kdelibs-3:3.1 and |
48 |
>=kde-base/kdelibs-3:3.4 . |
49 |
|
50 |
|
51 |
As its the only viable means I see of solving such dependencies, it |
52 |
also seems to be quite prone of breakage. To simply lock down SLOT |
53 |
depends would propbably not cause as much problems, however. |
54 |
|
55 |
//Spider |
56 |
|
57 |
|
58 |
-- |
59 |
begin .signature |
60 |
Tortured users / Laughing in pain |
61 |
See Microsoft KB Article Q265230 for more information. |
62 |
end |