[Yum] PATCH: handle more checksum in repomd file

[James Antill]

Miroslav Suchý <msuchy at redhat.com> 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.
-------------- next part --------------

 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 at and.org