On śro, 2008-12-03 at 11:30 -0800, Brock Pytlik wrote: > Michal Pryc wrote: > > Hello Brock, > > I am rewriting few functions on the package manager side and I found a > > little problem. > > > > Basically as part of fix for: > > http://defect.opensolaris.org/bz/show_bug.cgi?id=4628 > > > > We need to specify from which authority the package will be installed if > > the package have the same name: > > > > Package_A (default) > > Package_A > > > > Currenty to install the correct one we need to pass to the plan_install > > function the package stem instead of package name. The same is with > > removal of packages. > > > > The fmri.get_pkg_stem() returns for the default repository the stem in > > the format: > > pkg:/Package_A > > > > For non default repo: > > pkg://authority/Package_A > > > > This works perfectly and the proper packages are installed/removed. > > The problem stars when I am trying to call get_changes() from > > PlanDescription, which is required to reflect changes on GUI data mode. > > > > The get_changes() returns list of PackageInfo objects which contains the > > self.pkg_stem. Everything would be fine, but this is not the stem from > > the fmri.get_pkg_stem(), this is the package name. > > > > Is this a bug or desired behaviour? Should I use the steam to pass to > > the plan_install? If not how to plan the install/remove for a package > > with the same name but non default authority? The last question is how > > to identify the package from the get_changes() list, should I use the > > stem or simply use authority + pkg_stem, but then I need to build stem > > to pass to the plan* methods. > > > I'm lost here. If you've already made a plan, then (presumably) you've > passed in pkg://auth/Package_A if they've selected the auth repo instead > of the preferred one. Hi Brock, That is true. Since the API doesn't have any list operations we are taking the list of the packages from the image.inventory. The returned list is the list of fmri objects which contains the stem's through the fmri.get_pkg_stem()
The problem is when all operations are done, we need to update list of packages in the GUI data model. To save a lot of calculations, the list of packages which needs to be updated on the GUI side after installation/removal/update (for example icon and status in the row) is made of the list of packages which were found from the get_changes(). We know that only those packages will be touched and no other as this is the result after evaluation. This worked fine when we were comparing only the names of the packages, but there was a problem that two same names but from different authorities were only shown in one authority. Now once two same names can be found in two different authorities, there is problem identifying which one to update (the identifier is the authority and pkgname which is available from PackageInfo, but then we need to calculate the stem to compare or use other way). There are two solutions to this problem in my mind, the GUI data model needs to store either: - name and the authority We will need to calculate the stem that will be passed to the api planning methods and then we will need to find out which packages should be updated after executing the plan or the api will need to have some option to specify the authority for each package passed to the plan. - name and the stem We will need to calculate the stem after executing the plan to make sure we are updating the proper package in the data model, or the api should contain the stem and the name of the package. please let me know if you understand the problem now. best Michal > Or, are you saying there's a display issue? If > that's all this is, then I'm confused as to why the authority and > preferred authority fields of PackageInfo wouldn't have the information > you need. > > Fundamentally, I don't understand why you'd ever be feeding the output > from get_description back into plan_X. The api isn't designed for that > flow, and certainly hasn't been tested like that. > > Brock > > best > > Michal > > _______________________________________________ > > 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
