* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-02-15 01:32]: > 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.
Yes, that's right. Let's do this in the next set of changes. > > 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? Yes, this would be great. Thanks Stephen -- [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
