Miroslav Suchý <msuchy@xxxxxxxxxx> writes: > James Antill wrote: >> I think it's worse than that, for instance does anyone know what >> 3.0.1 will do? Or 2.4.0? > We can try. I'm willing to test it. I will have to do it anyway. > >> Better than that, what's the point in having two checksums in >> repomd.xml for a single primary ... when the .xml and/or .sqlite data >> for primary will only use a single type (yum-metadata-parser just >> picks the "last" (from the xml parser)). > > What if it really contains more checksums: SHA256, SHA1 and MD5 as > last. Yum will then pick up md5 and will use it. Despite the weekness > of md5, and despite availability of SHA256, which is preffered.
So let's pretend that whatever problem¹ you have that you think requires having two sets of checksums all the way down the metadata is needs to be fixed. So we have: 1. checksum data in metalink for repomd.xml 2. checksum data in repomd.xml for MD files (primary, filelist, etc.) 3a. checksum in primary.xml for package files. 3b. checksum in primary.sqlite for package files. 4. checksums in rpm. ...#1 already supports multiple checksums, probably isn't use by Spacewalk anyway. #2 is what you are talking about and yes newer versions of yum could be made to be "cleverer" and it _might_ be possible to provide guarantees about what happens on older yum's (so they don't die). Note _might_, this would need not only testing but things like guarantees that libxml won't change the order in which nodes are returned (and dito. guarantees on the generation side). All of which is decidedly unXML. #3a is mostly the same problems as #2, except lots more code and we'll be dealing with C code. On the other hand y-m-p probably hasn't changed that much, so we could maybe reason about what all versions do better. #3b is a complete disaster, it requires we change the schema which means incompatible versions of .sqlite ... which is obviously not backwards compatible, thus. making most of the above hacks worthless, IMNSHO. This is also likely a performance regression (although maybe only a slight one). #4 as anyone dealing with Fedora will tell you this requires a newer version of rpm than is in RHEL-5. Again making most of the hacks to have one repodata. for md5 and sha256 worthless, IMO. >> If you need sha/md5 and sha256 support you need to create a full set >> of repodata, IMNSHO. > > What do you mean by "full set of repodata"? Can you elaborate? I mean everything: repomd.xml, primary etc. etc. >> For spacewalk just default to sha or md5, and >> a way to change it ... and use that change on the official servers. > > No way. Sorry. But if yum do not see this as benefit, we will have to > solve this ourself in yum-rhn-plugin. Good luck with that. ¹ It'd be nice if you explain this, other than to say you must have it. -- James Antill -- james@xxxxxxx
_______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
