On 12/10/11 12:15 PM, Brock Pytlik wrote:
On 12/08/11 18:41, Tim Foster wrote:
I wonder if this code is sufficiently complex that it warrants a more
general discussion of the approach to be put in
./doc/pkgdepend-primer.txt or somesuch?
I'm happy to write such a doc, but I'm not sure what I'd put in there. I
think the basics of pkgdep are pretty simple, really things only get
confusing when variants get involved (at least from my perspective).
Maybe we can talk next week about the kind of info that might get put in
it. I don't think it should get as low level as documenting code or
functions, since that info should be comments in the code itself.
Sure - this shouldn't get in the way of putting back this wad, I'm just
concerned about how well a new pkgdepend maintainer would cope if you
fell under a bus or something.
I think I'd like to see more worked-examples of how the code runs: any
time I have to do anything with variants, I end up firing up a python
interpreter, and just walk through cases watching what happens to the
Variant* objects as we go. It might be good to do that here, at a high
level?
Ultimately though, if the code is crystal-clear to everyone else, then
I'm happy to spend more time trying to get my head around it, rather
than have you write a document for an audience of one :)
<snip stuff about array indices, which you address in a later mail>
line 950 - the comment here is terse - could it explain a bit more
what it's trying to do when grouping? I was a bit lost in here, I admit.
I'll give it another shot. How's this:
"""The goal of this function is to produce the smallest list of (info
list, VariantCombinations) tuples which has the following properties:
1. The intersection between any two satisfied sets of the
VariantCombinations must be empty.
2. If a piece of information was satisfied under a particular
combination of variants, that information must be paired with the
VariantCombination which has that combination in its satisfied set.
Note: A piece of information can appear more than once in the result.
The 'lst' parameter is a list of tuples. The last item in each tuple
must be a VariantCombination. The rest of each tuple is the "piece of
information" discussed above."""
That seems better - thanks. The 'info list' is just baggage here,
right, it doesn't get used as part of the grouping calculation?
line 1270 - I don't see why you're skipping the order of the
is_successor check from the previous version of the code? If this is
correct, then does the comment at 1266 still hold?
Do you mean switching the order?
Yep.
> The comment on 1266 still holds, the
code was just wrong previously. Here, comp_fmri is the target fmri of a
require dependency. c is coming from the set of fmris from the
require-any dependency currently being checked for redundency. So, we
can drop the require-any dependency if there's already a require
dependency on a successor to c. Ie, if the require-any depends on a@1,
b@2 c@3, then a require dependency on c@4 means we can drop the
require-any dependency, but not a require dependency on c@2.
Thanks for the explanation - that makes sense now.
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
