> I'm not sure I agree that bad fmris in a catalog is a retryable exception
> (except in the truncated catalog case). It's more likely that the catalog
> data itself is bad, and that trying again won't give us any better results.
> And since we're dropping the bad catalog entries on the floor anyway, we
> probably don't have to raise an exception at all.
Yeah, you're probably right that it isn't retryable. I've put together
a new webrev that treats the malformed FMRIs as a fatal error. If this
is indeed depot-side catalog corruption, the client should see an error
and report that to the depot maintainer.
> Now, it might be nice to warn the user, or log something, but being silent
> is probably fine for now.
The current catalog drops obviously malformed lines on the floor, but
writes unrecognized lines that are properly prefixed back into the
catalog. I think it's a toss up about how to handle this corruption.
> In updatelog.py, only the PkgFmri construction needs to be in the try
> block; the stuff dealing with "line" can be outside it, and thus not quite
> as squished to the right.
I missed this in my last pass, but I'll go back and fix it now. A
webrev with all the changes except this one is available from:
http://cr.opensolaris.org/~johansen/webrev-6222-2/
Thanks for looking at this.
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
