1 |
On Friday 09 December 2005 04:03, Zac Medico wrote: |
2 |
> Jason Stubbs wrote: |
3 |
> > On Thursday 08 December 2005 16:44, Zac Medico wrote: |
4 |
> >>The middle hunk fixes a problem with block atoms that do not match any |
5 |
> >>packages. Previously, these atoms would not make it into the okay_atoms |
6 |
> >> set which caused unresolved dependencies. |
7 |
> > |
8 |
> > Are you sure about this? |
9 |
> |
10 |
> Well, I'm pretty sure. You're analysis seems to be perfectly correct except |
11 |
> for 2 points that you haven't accounted for: |
12 |
> |
13 |
> 1) The atom.key != child.key optimization prevents the atom.match(child) ^ |
14 |
> atom.blocks bit from working in the case that my patch handles (block atom |
15 |
> that does not match any package). |
16 |
> |
17 |
> 2) Without the atom.key != child.key optimization, the original algorithm |
18 |
> would bail out early, before all packages have been checked. We need to |
19 |
> ensure that the atom does not block _any_ of the packages before we add it |
20 |
> to okay_atoms, otherwise, we risk choosing the wrong atomset/combination. |
21 |
> Note that checking all the packages _does_ introduce a performance penalty |
22 |
> for block atoms. |
23 |
|
24 |
Damn optimizations. :| |
25 |
|
26 |
Both points are correct. |
27 |
|
28 |
-- |
29 |
Jason Stubbs |
30 |
-- |
31 |
gentoo-portage-dev@g.o mailing list |