On Thu, Mar 26, 2009 at 01:44:30PM -0500, Shawn Walker wrote: > 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.
Perhaps I'm confused, then. I thought the known / state element of the tuple indicated the state of the publisher -- that is, if I had an "opensolaris.org" publisher that I'd deleted, you were marking it False when it was referenced in the catalog. But I can easily tell if I've got a particular publisher defined, can't I? This isn't a per-package state, but a per-publisher state. >> 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. I think that would help substantially, though obviously the code gets a bit more complex that way. It'd be nice to know what the working set increase is from gate bits to your current bits, and then to this. >> 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. If you're not using it yet, or aren't about to, then don't add it. Ask the SMF folks about tracks and invisible trains. >> 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. Indeed. We're only ever calling this function for install and update, so no package gets uninstalled. > 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. Okay. >> - 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. There are, in fact, a handful of astral alignments which can make me appear to be right. Don't be fooled. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
