Brock Pytlik wrote: > svc-pkg-depot: > Given the changes on lines 76 and 95, I think that similar changes > should be made for 86 and 105 (and elsewhere?) > > retrive.py: ... > I'm somewhat confused as to why you only look at the end FMRI for target > in __get_intent_str, either I've got the role of fmri and target > backwards, or there's a constraint being taken advantage of that's > imposed by how the function is being used, I think.
Because the list of targets is a "stack" built as packages are processed. The last one in the list is the one being processed *currently*, while the one immediately preceding it is the reason it's being processed. So, for example: * User executes "pkg install A" * Client adds pkg A to target list * Client retrieves and reads manifest for pkg A * Client discovers pkg A depends on pkg B * Client adds pkg B to target list * Client retrieves manifest for pkg B * Client clears target list after processing the initial target (pkg A) and all of its dependencies The list of targets should look like: ["A", "B"] > I think it's unfortunate that we'll lose some of our internal cross-repo > information. Perhaps that's something that could be added to either > image or repo configuration so that, for example, when a contrib or > extras package had a dependency that p.o.o satisfied, we could know > that, but if a package from life-for-solaris was involved, then it would > just be "unknown". I agree, however, I don't believe it can't be added to the repository configuration since that's an untrusted source as far as the client is concerned and it would have to rely on the repository to tell it what to do. Once we have a more concrete way to compare authorities, this can be revisited. Cheers, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
