Danek Duvall wrote:
Shawn Walker wrote:
src/modules/client/image.py:
...
* 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.
I don't understand. What's being merged? In particular, the "states"
variable is being created completely anew each call, so discarding those
states from "states" won't make any difference. Am I misunderstanding the
code, or your comment?
See lines 1329-1331. Only if the package didn't previously exist in the
known image catalog will the state information be completely new. This
ensures that state information for packages where the publisher no
longer exist in the image, or who does not have a network repository
(missing catalog/offline too?) will still keep their state information.
If I'm wrong about this, please tell me, since that would be a bug :)
src/modules/server/transaction.py:
...
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?
I dunno. If we do that, then you'd have to abort the transaction and start
from scratch, which could suck (if you were publishing a large package and
accidentally sent it an obsolete tag). I originally had XXX comments here
suggesting I should just go ahead and abort the transaction then and there,
but that seemed overly harsh. Still, I'd rather do that than wait until
they close before telling them (again) there's a problem.
The abort makes sense to me since they're likely to have to redo the
publication anyway.
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.
I can pull this test out and put it into t_pkgsend.py, if you think that
would make more sense. Is there any reason to expect that file: repos
wouldn't take the same codepath, though?
They subtly don't; in the sense that any in-memory attributes you're
setting, etc. are list for each operation. Unlike the depot which is
persistent...
Also, although it's slower, I'd be certain to check one-by-one action
publication in addition to bulk.
Why?
Because I suspect it will give you different behaviour, or that your
checks may not work as expected. I discovered this the hard way many
times during my publication work.
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
