On Tue, 2008-07-22 at 12:57 -0400, seth vidal wrote: > On Tue, 2008-07-22 at 12:53 -0400, James Antill wrote: > > I have 4 branches which might be worth putting in for 3.2.18, everyone > > may or maynot have looked at them before and they aren't "obviously > > simple/wonderful" enough I've just committed them, so I'll just list > > them and you can tell me what you think... > > > > _quickWhatProvides > > group_pc > > repo-sacks > > * repomd-checksums > > > > repomd-checksums > > > > This adds a checksums dict and a length member to the RepoMD object, > > this is mainly for new style mirror lists. I know Seth had some > > reservations about having "length" be calculated as a checksum ... but I > > can't see another easy way to do it. > > > > Like I said before - not crazy about a lenth checksum b/c it really > isn't.
Yeh, it's just an easy way to get the length by re-using the fake file object I created to get the checksums. I can try and make it a bit less evil looking. > I have 2 thoughts on this one patch: > 1. we might as well and write it with hashlib now instead of sha > directly, just for future preparation. Yeh, I'll fixup misc today. > 2. would it make any sense to make the 'checksum' of the repomd be the > checksum of the concatenation of the repomd object's checksums? That way > the actual repomd.xml FILE doesn't matter, just the data that it is > carrying. So the only two problems I see by this are: 1. This means mirrormanager is going to give us _long_ checksum strings (esp. as we'll have to do checksum and openchecksum ... I think[1]). 2. We can't move to SHA256 etc. without changing the repomd.xml defined checksums. ...I'm also not sure that we want to ignore other "benign" changes to the file, although if it's the right size and has passed gpg checking it's probably fine :). So I'm not apposed to it, if you think that's a better way to go. [1] Also if we have type="sha" and type="sha256" meta-metadata, I'm not sure what we'd do for the overall checksum (esp. if someone do the awesome and some of the data entries didn't have sha256 checksums). -- James Antill <[EMAIL PROTECTED]> Red Hat
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
