image.py:
set_package_state: It looks to me like there are paths through the code
which could end up hitting line 978 wihtout defining icat. For example,
suppose 'state' is not installed nor uninstalled, but installed is in
'states' wouldn't that mean icat wouldn't be set when you hit line 978?
It might be too late for this, but I wonder if a dictionary for the
states wouldn't be a better data structure and result in clearer code.
With the sets approach, there's nothing inherent in the structure that
prevents a package from bring both installed and uninstalled. A
structure like state[installed] = True|False, state[version]=0|1, etc...
might make things easier to deal with.
1167-1168: might we want to store the optional dependencies as well? I'd
think the times when we want the require dependencies, we'd often want
the optional or incorporate ones as well.
1244: The location of these comments is confusing. I'd suggest moving it
down to line 1278. Same with the comments on 1282-1284.
imageplan.py:
307: Why is this check necessary since you've ask the catalog for
dependency actions? Or maybe I should ask why cat.DEPENDENCY spits back
set actions along with depend actions...
catalog.py:
1054+: I'm confused about the logic here and why DEPENDENCY results in
the set of actions that it does. If nothing else, renaming the constant
might be helpful.
1326: 'excludes' is the list of things that should be allowed? .... and
it's empty be default...
1371, 1488, 2231, 2315: this seems like it should raise an exception
rather than assert, unless you've done a check higher up to prevent this
from happening
Brock
Shawn Walker wrote:
Greetings,
The following webrev contains fixes for the following issues:
11359 catalog should offer lazy-load mechanism for action metadata
11360 transformed v0 catalogs should have catalog.version of 0
11361 packages should be marked with catalog version
11410 t_api TestPkgApi tearDown sporadically fails
webrev:
http://cr.opensolaris.org/~swalker/pkg-11359/
Change Summary:
* added transparent lazy-load capability for action data in
preparation for native v1 catalogs, allowing catalog consumers to have
one code path for both v0 and v1 catalogs
* fixed sporadic t_api.TestPkgApi tearDown failure
* added new methods to retrieve actions and variants for catalog entries
* changed image class to use new catalog action/variant methods in
preparation for server-side v1 catalogs
* increased performance of image-update or large install operations by
simplifying catalog status updates
* added method to catalog class to append() catalogs together (makes
it easier to consolidate multiple catalogs)
* changed image to mark packages with the version of the catalog they
came from (this may prove useless later, but I anticipate using this
for the list api work)
* added lots of unit tests for new catalog functionality
Cheers,
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
