Danek Duvall wrote:
Here it is:
http://cr.opensolaris.org/~dduvall/pkg-obsolete-stage/
doc/client_api_versions.txt:
Funny, I made the same change for the list API work I'm doing.
Shouldn't be much conflict as a result :)
src/modules/client/image.py:
lines 1347-1360: A few things:
* By retrieving the dependency catalog entry directly, this will
keep this code from working for anything but package repositories with
v1 catalogs. This may have been intentional, since if you use
src_cat.get_entry_actions() the action data would be lazy-loaded
(triggering a manifest retrieval) which would probably be undesirable.
* pass must_exist=True to get_part(); otherwise a new part will be
created if it doesn't already exist (sorry, this is very subtle)
* You should discard the OBSOLETE and RENAMED states around line
1348 (every time) since this is a merge operation. This will ensure
that the states information accurately reflects what is in the catalog.
Unlikely to create an issue, but theoretically possible.
src/modules/server/transaction.py:
lines 125-128: I believe these properties are in-memory only, so
won't survive a depot restart, and won't work for one-by-one publication
using pkgsend and file://. If a user publishes all of their actions
except "set name=pkg.obsolete" (or vice-versa) and then restarts the
depot, or uses pkgsend with a destination file:// repository, then the
checks in add_content will pass. As a result, you may want to consider
serialising this extra transaction information and then re-loading it in
re-open.
lines 399-441: Curious, why do this check in add_content instead of
close()? Was it an to attempt to fail as soon as possible?
One concern is that if they weren't paying attention to the exit
return code of pkgsend, and they were doing one-by-one 'add' operations,
this would appear to cause the server to fail all of the bad adds, but
the close would still succeed. Should you record the transaction error
in a list, and if that list is populated, fail on close with all of the
accumulated errors?
src/tests/cli/t_pkg_install.py:
lines 2837-2841: since you've combined the publication and install
tests here, you need to test file:// publication as well. Same goes for
any other tests where you're checking for publication failure. Also,
although it's slower, I'd be certain to check one-by-one action
publication in addition to bulk. Don't forget that you need to call
depotcontroller.refresh() if you're using file:// publication to publish
to a repository currently in use by the depot server.
Otherwise, seems fine.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
