On 02/ 6/11 07:02 PM, Tim Foster wrote:
Hi Brock,
On Thu, 2011-02-03 at 22:23 -0800, Brock Pytlik wrote:
[snip]
Does that make sense?
Yikes, yes, that does make sense :) Thanks for the example.
Yikes indeed - I believe I've spotted a flaw in my reasoning
unfortunately. In my example, we have:
depend pkg.d.depend.file=passwd pkg.d.depend.file=shadow \
pkg.d.depend.path=foo \
pkg.d.depend.path=bar
The following files would satisfy the dependency:
foo/passwd
bar/passwd
foo/shadow
bar/shadow
But, say we want to bypass only "foo/passwd", we need to split off a
new
dependency so that we instead generate the two dependencies:
depend pkg.d.depend.file=passwd pkg.d.depend.file=shadow \
pkg.d.depend.path=bar
depend pkg.d.depend.file=shadow \
pkg.d.depend.path=foo \
pkg.d.depend.path=bar
The problem is, that we want any *one* of
bar/passwd
foo/shadow
bar/shadow
to satisfy both dependencies, essentially grouping them together. At
the moment, without linking the dependencies, this will result in an
unsatisfied dependency if we happen to deliver bar/passwd but not one of
either foo/shadow or bar/shadow.
We're not seeing this problem in the ongoing work on the ON manifests
yet as we haven't had to bypass a dependency that generates multiple
pkg.debug.depend.file values. (python modules are the only dependencies
that do this at the moment, and even then I'd imagine the vast majority
of users would simply bypass all of "*/foo.py" "*/foo.pyo", "*/foo.pyc"
"*/foomodule.so" "*/foo.so" and the standard runpaths to locate
"foo/__init__.py", avoiding this scenario completely )
In order to fix this, I suggest a "pkg.debug.depend.group" attribute to
provide hints to pkgdepend resolve on how groups of file dependencies
are related.
Dependencies that get spawned from a common parent dependency via the
bypass-generate mechanism would get the same auto-generated group-tag.
At the end of 'pkgdepend resolve', we scan the err list looking for
errors tagged with group tags that have already been marked as
satisfied. (which means we need to add pkg.debug.depend.group fields to
each of the Exception types used by pkgdepend resolve)
I can't think of a use-case where we'd want to expose this functionality
to manifest authors, hence the use of the internal attribute name, but
I'm all ears if anyone has one?
Apologies for not catching this before seeking code review - I'm
investigating the fix for this at the moment, but wonder whether it's
something we really want fixed before this wad goes back?
In the meantime, I've got the 'generate' part of the fix done now - the
'resolve' side is a bit more involved (need to mark each error produced
with the pkg.debug.depend.group tag responsible, if any)
Wow, that's complicated :D
Just as a suggestion, had you thought of perhaps adding a "completepath"
tag to the generated depend action. It could contain the entire path to
look for and then you could remove the file and path tags. That would
mean you wouldn't need to split dependencies (which would mean you
wouldn't need to worry about how to merge them back in later). If you
decide to go this route, it might be worth thinking about whether we
could/should do this transform for all actions (ie, convert all
generated depend actions so that they only have completepath tags, and
not file or path ones). I don't think any part of resolve works based on
the separation of file and path.
On a similar note, if you like the approach with the group tag better, I
think it's worth considering breaking up all multi-path or multi-file
depend actions as you're doing above. It'd be nice if we had a single
path through this code, instead of only using the group code (or the
completepath code) on Tuesday during a fall eclipse.
If you go with the complete path idea, I think it might be as simple as
moving the step where we run make_paths (in publisher/dependencies)
during the generate phase instead of the resolve phase.
Let me know what you think,
Brock
[snip]
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
