Stephen,
Thanks for the feedback, it's much appreciated.
> client/image.py:
>
> 600,
> 625. I don't think this is right, unless we straighten out the
> handling of package authority state in the case of
> the default authority (authority == None). The scenario I'm
> thinking of is where one takes a package in the shared namespace
> from authority A, switches one's default authority to B, and
> then attempts to update that package.
I'm not sure I understand. We may want to discuss this offline
tomorrow.
The rename is a per-catalog operation. We keep catalogs on a
per-authority basis. We don't presently have any concept of a shared
namespace. If I'm understanding you correctly, we'd actually want to
implement a shared catalog, or a distributed catalog consistency
mechanism, otherwise I'm not certain how we could possibly enforce this
in a way that is different from what is in the code now.
Your example is that we download a catalog from authority A and then
switch to authority B. We have to get a new catalog from authority B.
Determining that packages are equivalent based simply upon name seems
risky here. A and B could both have the same package, but they may have
different contents, or in the case of rename, A might have package foo
renamed to something else, even though catalog B has no record of that
rename. Without checking that the authorities match the packages that
are being compared, I don't see another reasonable way to determine
whether packages are equivalent.
I know we had talked about implementing a workaround where packages that
were installed from the default authority were given either authority =
None, or authority = <special token>. If you're observing that this
code won't work when we implement that workaround, I agree. We'll need
to make sure we check for None or <special token> wherever we compare
authorities. I assumed that when I work this out, I'd have to update
all of the places where we performed authority comparisions for package
equivalency.
> depot.py:
>
> 185ff. Humour me and add a rename count statistic to
> pkg.server.config.
Added.
> updatelog.py:
>
> 270. Please add a comment referring to catalog.py's module docstring
> for all format strings. You might consider defining them there
> as well.
Ok.
> publish.py:
>
> 183. (Nit.) I'm not sure I like these "server failed" messages, but
> I'll let them go. For instance, they emit neither the attempted
> operation nor the transaction ID. In the case of rename, you
> can produce a better error message for the 404 case involving
> the RenameException. I know Shawn and Danek are discussing new
> response codes in another thread, but I wonder if we should
> just have an auxiliary code are part of the exception...
These error messages turn out to be a bit more detailed than errors we
would get in previous versions of the code. I believe Danek putback a
bunch of support to make this stuff more verbose. There's no
transaction ID associated with a rename, because it's operating on
packages that are already in the repository. It either succeeds or
fails. As an example, I published a rename that I knew would fail:
pkgsend: server failed (status 404): Src FMRI pkg:/[EMAIL
PROTECTED],5.11-0 must
not be in catalog
Is it the server failed part that you object to here? It seems like it
would be easy enough to change this to:
pkgsend: rename failed (status 404): Src FMRI pkg:/[EMAIL
PROTECTED],5.11-0 must
not be in catalog
Would this be satisfactory, or am I missing another part to your
objection?
Thanks again,
-K
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
