On 05/ 7/10 03:11 PM, Danek Duvall wrote:
Brock Pytlik wrote:
http://cr.opensolaris.org/~bpytlik/ips-15843-v1/
As far as I can tell, you're resolving the dependencies implied by a file
only in the proto area that the file is found in, which isn't the right
thing to do. Dependencies can be resolved in any of the proto areas, which
makes me think that proto_dir isn't per-action, but still needs to be
passed around as its own object, only now it's a list.
This had me confused originally too. Remember there are 2 phases
generate and resolve. Generate actually looks at and examines the files,
resolve merely looks at manifests. So, when doing the generate phase, we
need to look @ the files, so we need the proto_dirs around to see where
the files might be found. Once we know which proto_dir a file is found
in, we have all the information generate needs.
Resolve, on the other hand and including the internal resolve deps bit
that generate does, always works on image-relative paths. The proto_dirs
are totally irrelevant at the resolve stage.
The test from lines 748 to 755 in t_dependencies actually demonstrates
resolving internally with files delivered in two different proto areas.
We shouldn't have two ways of specifying proto areas. I would start
obsoleting (by undocumenting) the "proto_dir" argument to pkgdepend
generate. It will take precedence over directories specified by -d, but we
should start discouraging its use. Once ON has a chance to cut over to
using only -d, then we can get rid of it.
Ok.
The usage message for pkgdepend should use the same syntax for describing
the -d option as the man page does.
Ok.
What's up with process_hardlink_deps() passing "" as proto_dir to
HardlinkDependency?
The proto_dir is used by make_relative to relativize the run_paths.
HardlinkDeps never call this function and thus have no use for the
proto_dir. Which is a good thing becuase with this wad, the hardlink
action doesn't have its proto_dir set, so it doesn't have a value to
pass in there in the first place. If you prefer, I can refactor the
Dependency class structure in base.py to create more levels so that it
doesn't need to pass in a proto_dir at all.
Thanks for taking a look,
Brock
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss