Danek Duvall wrote:
On Tue, Mar 24, 2009 at 12:39:53AM -0500, Shawn Walker wrote:
http://cr.opensolaris.org/~swalker/pkg-6856/
Why are you putting the publisher state into the catalog data structure?
It's a minor extension of the publisher information we already record in
the catalog data structure; I didn't view it as publisher state.
Can't inventory() determine that quickly at runtime? Part of the reason
Not as far as I know.
That was the whole point of the change; so I could differentiate between
package stems that are installed and those that are installed *and*
present in the corresponding publisher's catalog.
I didn't think searching through the entire publisher's catalog would be
efficient when the information could be so cheaply obtained.
that pkg list is getting slow again is that the pickle is getting huge, and
while we need to fix that, this isn't going to help at all. (That said,
the code for all this looks fine, though I might get rid of publist from
__inventory() entirely, and just use pubstate, with .keys() when
necessary.)
I could re-work the structure slightly so that this information is only
recorded for entries that are "discovered" when checking installed
packages and are no longer in the publisher's catalog. That should
limit the impact to catalog entries that are for installed packages for
a removed publisher.
image.py:
- line 2286: Given that state is always passed in as PKG_STATE_INSTALLED,
why not default this argument to it, or eliminate the argument
entirely?
Because I intended this to be able to be used elsewhere and wanted to
make this generic.
Are any of the tests for these states? All the new tests seem to be
for the publisher removal bits.
The new tests should be covering these states indirectly; publisher
removal or multiple publishers with the same fmri causes most of them.
- line 2315: How would we get in this state? That is, if the package is
no longer in any publisher's catalog, how would they have ended up in
the list of matches?
If the package is installed, but the publisher has been removed, then
it's in the list of possible matches so that uninstall can still be
performed.
However, this is not for *that* case. This logic is for the case where
the installed package belongs to publisher A, but publisher A no longer
has the fmri in the catalog, but publisher B does.
- line 2452: Given that we only support one preferred publisher right
now, will the filtering ever do anything?
It seems as though you're right. The only multiple matches that should
happen for the preferred case should be truly ambiguous matches.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
