Tom Mueller wrote: > Brock, > During the installation, the licenses to be displayed have to come not > only from the packages that the user selected, but also from the > dependencies (recursively). Does the package plan interface have the > ability to get the list of fmri strings to pass in after the plan has > been evaluated? Yes, the consumer creates the plan by calling plan_X. Retrieves the plan using describe. Then pulls out the destination fmri strings and passes those to info. Yeah, that's a little ugly for the consumer, and maybe it can get cleaned up in the future. But it is possible today. > > Also, as we move forward, it will be necessary to have access to other > meta data about packages, such as the change list. So would the > PackageInfo class be extended to include information about other actions? Could you explain what you mean by change list?
The reason I made PackageInfo be a class, rather than a list, or dictionary, or tuple, was to make it easier and safer to add more meta-data to it if we need it. I'm not clear what meta-data is missing, but if it is, it can be added and the older code would continue to function as expected. > > Since an action is a fundamental concept in pkg(5), it seems that > Action objects should be exposed in the API. This is unclear to me, though it's certainly possible. It's certainly not necessary for the pieces the interface handles now. The place I can see perhaps needing this is contents. Are there other commands which would need direct access to actions? If Actions need to be exposed, or some limited piece of them (like PackageInfo is a limited piece of FMRI with a bit of manifest thrown in), they can be added. Brock > > Tom > > > Brock Pytlik wrote: >> Michal Pryc wrote: >> >>> [snip] >>> For the 2008.11 we will add license tab for packages. If this will be >>> not provided by the API then we will need to pull the license calling >>> other methods. >>> >>> >>> >> I looked into this a bit, and I've added a new piece to the API, info. >> It lets the caller retrieve package information for all the fmri strings >> provided. In this function, there's an argument which chooses whether or >> not to retrieve the licenses. Are there other bits of information you >> might need for a package which aren't captured by PackageInfo? Will this >> info function provide the interface to the licenses you need? >> >> def info(self, fmri_strings, local, get_licenses): >> # fmri_strings: fmri names >> # local: whether information is gathered locally or remotely >> # get_licenses: whether to retrieve the text of the licenses >> # Returns: A tuple consisting of: >> # a list of PackageInfo's for all fmri's whose >> information >> # was found >> # a list of all the fmri strings whose information could >> # not be found >> >> >> class PackageInfo(object): >> def __init__(name=None, summary=None, >> state=None, >> authority=None, version=None, >> build_release=None, >> branch=None, >> packaging_date=None, >> size = None, fmri = None, licenses=None): >> self.name = name >> self.summary = summary >> self.state = state, >> self.authority = fmri.strip_auth_pfx(authority) >> self.version = version >> self.build_release = build_release >> self.branch = branch >> self.packaging_date = packaging_date >> self.size = size >> self.fmri = fmri >> self.licenses = licenses >> >> >> Thanks, >> Brock >> >> [snip] >> _______________________________________________ >> pkg-discuss mailing list >> [email protected] >> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss >> > > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
