On 08/ 9/10 01:03 AM, Shawn Walker wrote:
Greetings,
The following webrev contains changes or fixes for the following items:
16744 repository multi-publisher on-disk format should be formalized
and implemented
[snip]
webrev:
http://cr.opensolaris.org/~swalker/pkg-repo-format/
[snip]
Cheers,
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
I reviewed this mostly looking at search issues and potential collisions
with the manifest signing wad that's out now.
Currently the manifest signing wad adds/removes certs to/from the repo,
I assume that after both wads land, the right answer is to have the
certs added to particular publishers and as part of adding the cert, a
publisher property will be set?
So instead of:
/usr/bin/pkgrepo add-signing-ca-cert path ...
it will be:
/usr/bin/pkgrepo add-signing-ca-cert publisher path ...
Is that correct? I don't think the -p option is the right approach here
because by default, publishers should not be sharing certificates so
making the publisher argument optional seems like it would cause problems.
modules/indexer.py:
With the locking going in, is there any reason to retain the consistent
opening logic? Are you leaving it around purely for backward
compatibility? If so, can you file a RFE to remove that functionality
once we've decided enough time has passed?
I think the locking here is fairly complex because they keep getting
picked up and dropped. I think it would be easier to understand and
maintain if we did either what we've done in other places w/ wrappers
which are responsible for taking and dropping the locks, or keep the
existing approach but make each function take the lock only if
self.__locked is False, and then dropping the lock only if it was taken
in that function's invocation.
Why not have the indexer use the same makedirs as misc provides? The
reason for having it raise search_errors was that it was a module shared
by both client and server, while api_errors were client only. Since this
no longer the case (server modules import misc which imports api_errors)
we might as well consolidate both the exception space and the makedirs
functions.
modules/server/depot.py:
What's the timeout of .5 seconds on line 2026 buy?
Why can't more than one background task be queued?
Do the background processes happen in the same process or are they
forked out by cherrypy? If it's that same process, then that concerns me
as indexing previously happened in a separate process from the depot,
which meant the memory it used was returned to the system when the
indexing was done, instead of being attached to the depot for as long as
it was running.
There's no way to abort a task running in the background?
Is the user told that the operation they just instructed the depot to do
is being done in the background and that they'll need to check the logs
for errors? Suppose a user wanted to refresh-packages and wait to do the
next step until that was finished, how would they accomplish that? Would
they loop polling stauts/0 until the operation they cared about was
marked as finished? It seems that, based on what I understand about how
indexing locking currently works, this wouldn't necessarily work because
the user could have their status/0 request processed in one of the times
between indexing dropping and picking up the lock, meaning the status
would be reported as online instead of indexing.
modules/server/repositoy.py:
Why doesn't open need to lock the repository anymore?
tests/api/t_api_search:
line 1257: Why the change from True to False?
line 2076: This shouldn't be needed for this class
line 2224: Probably worth including the destination in the debugging
Thanks,
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
