On Tue, Sep 01, 2009 at 05:36:22PM -0500, Shawn Walker wrote: > [email protected] wrote: >> Perhaps. The fact that the testsuite leaves tempfile turds everwhere >> continues to be a source of aggravation. Would you comment the code to >> state that you expect callers to rename this object if they want to keep >> its contents? I would really like it if you also added a __del__ method >> that removes the tempfile if it exits, unrenamed, when the object is >> destroyed. > > I would note that since renaming the file is a necessary part of the > operation, and this tempfile is created in the caller's specified > directory (in this case, catalog directory), not a temp directory, I > don't believe that's really necessary, but I'll still add it if you > believe so.
If this must happen as part of the operation, I'm a bit less concerned. What do we do if the caller's side of the operation fails? My expectation would be then that the caller cleans this up, but I don't remember seeing that. >>>> manifest.py: >>>> particular, it doesn't look like we take any action beyond raising >>>> an exception if verification fails. Bug 6011 details the need to >>>> re-download corrupt manifests. If we're able to determine that a >>>> manifest isn't valid, the transport needs to know that it encoutered >>>> an error while downloading the manifest, and we should re-download >>>> the manifest's content; however, I don't see either of these things >>>> happening here. Is this part of Phase III? >>> Yes and no. For the client to get the manifest signature data, the >>> server has to provide v1 catalogs. So the completion of the plumbing >>> work will be done in Phase III, but I will be opening a bug for >>> another enterprising soul to take advantage of the new aqueduct :) >> >> Yes, however the step that catches either a MalformedActionError or a >> MyManifestDidntVerify error ought to be generic. I would suggest that >> since we're going to the trouble of adding manifest signatures and >> catalog signatures, we should verify them both too. I'm willing to do >> the transport side of the work for both of these, but I think we need to >> be in agreement that this is part of the Phase III deliverables in order >> for that to happen. > > My current schedule demands don't allow me to personally be the party to > deliver those, so I'll have to pass. I'm putting all the plumbing in > place because it is so inter-twined with the existing work I'm doing, > but I really don't have the time to do the extra work on top of that. I disagree with writing code that's not going to be put into use. We saw what happened to the rename code that didn't get used. It got broken, and then lingered in a twilight of non-existence, and eventually had to be removed since it no longer fulfilled its intended purpose. I'm not asking you to do all of the work and I'm offering to help. I don't think it makes sense to putback code that's going to be used at some future indeterminate time. In particular, it would be bad if we discovered that the eventual verification method didn't return correct results when applied to historical manifest versions that contain these signatures. In order to ensure that this code works when it's putback, and continues to work, we should verify the manifests against their attached signatures. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
