Danek Duvall wrote:
On Thu, Mar 26, 2009 at 01:44:30PM -0500, Shawn Walker wrote:
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.
Again, this is definitely per-package state and it isn't just about the
publisher being defined.
The flag is *not* just for the case where the publisher has been
removed. The following cases might help better explain its purpose (and
these are all covered in the unit tests):
* user installs package A belonging to publisher A, then removes
publisher A, and then adds publisher B which also has package A
* user installs package A belonging to publisher A, then removes
publisher A, and then adds publisher A back with a *different*
repository which does not have package A in its catalog
* user installs package A belonging to publisher A, later they perform a
catalog refresh, and the repository no longer has package A in its catalog.
...there are probably a few more variations on the above theme, but it
should be clear that this is per-package state; not publisher state.
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.
I'll look into it.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
