We (Jan, Michal and me) did some brainstorming about SHA-256 support and
we come with following result:
Table:
rhnChecksumType: id, label, description, created, modified (we already
have this table)
rhnContentChecksum: id, checksum_type_id, checksum (PK is id)
and in tables rhnPackage, rhnPackageFile, rhnErrataFile... change md5sum
to content_checksum_id, which will be FK to rhnContentChecksum.
This is change from current logic in sha256-support, where is schema
with cardinality 1:N, to cardinality 1:1.
We believed (and our faith is supported by rpm maintainers) that there
will be never need to have related two or more checksum for one package
or one file from one package. That's why we lower the cardinality.
We find that even if we mix packages with different checksum (i.e. md5
and sha256) in one repo, you can mix in repomd different checksums and
yum will (should) understand it.
Benefits of this change is, that it is more general. I.e. if you have
tar/rpm package which contains other rpm, which is the same as some
other in rhnPackage, we can easily detect it.
BTW: the commits in sha256-support have been impossible to merge or
rebase in master, so I half cherry-picked and half rewrite to new branch
sha256-support2.
--
Miroslav Suchy
Red Hat Satellite Engineering
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
