On 01/13/12 10:58, Danek Duvall wrote:
Brock Pytlik wrote:
https://cr.opensolaris.org/action/browse/pkg/bpytlik/7129625-v1
manifest.py:
- line 531: "exclduded" -> "excluded"
- line 1098: "factorerd" -> "factored"
- line 1113: "if not excludes"? Why is this clause relevant only if
we're not loading from disk? This means that in order to get a
complete list of actions from a manifest, you'd have to create the
object with its excludes member set to EmptyI, rather than simply
calling this method with excludes=EmptyI. I assume we don't do the
latter anywhere?
No, I want this to be if excludes == EmptyI, which is the default for
excludes in this method. If you pass in anything else, then you probably
meant for it to have meaning. Also, it mirrors the same checks that went
in elsewhere in other functions recently.
I don't follow your third sentence at all. What it means is that, if you
previously excluded content on this manifest, you get that same view of
the world from the manifest. If you want a FactoredManifest that shows
you all the actions, don't call exclude_content on it. And yes, if you
create the FactoredManifest with excludes set to exclude sparc actions
(for example), then no, you can't go back and get them from this
FactoredManifest later.
- line 1115: Can you explain this? The first test is true if we
triggered the test on 1113, and ended up setting excludes to
self.excludes. So this is effectively saying that either excludes (as
passed into the method) or self.excludes is EmptyI, or they just happen
to be identical, and I don't understand why that would have to be the
case.
What's it's saying is that if you've previously called exclude content
on this manifest, and now you're using a different set of excludes to
view this manifest, that's a bug and you can't do that.
This approach to exclude content went in during the previous performance
wad and allowed significant memory and time improvements.
t_manifest.py:
- line 395: is this cleaned up automatically?
It's inside the test root, so yes.
Sorry if I'm diving too deep, but these changes are not obvious to me.
Perhaps a more detailed evaluation in one of the bugs would help.
Huh, I thought the evaluation in the bugster bug was pretty detailed.
I'm not sure what else to add there.
Hth,
Brock
Thanks,
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
