Deal with SOURCEPKGID, PKGID and HDRID

[pmatilai]

Related to #2633, rpm currently aliases RPMTAG_PKGID to MD5 and RPMTAG_HDRID to SHA1HEADER tags. This doesn't cut it going forward because said tags will no longer be there. In addition there's RPMTAG_SOURCEPKGID which refers to RPMTAG_PKGID.

We can sort of keep these alive by adding tag extensions that provide an identifying hash for the package. Differentiating between the header and the package id was always pointless IMO but even more so in v6 where the main header carries a digest on the payload too. So if we conclude that the header is what identifies a package, then we can conclude that pkgid and hdrid should be the same exact thing. And with >= v4 packages we can always calculate any hash we like on the immutable region, so we can eg use SHA256HEADER as the header ID and dynamically calculate it for older v4 packages that lack it.
Another difference between RPMTAG_PKGID and RPMTAG_HDRID is that the former has been in binary form, whereas the latter has been in ASCII form. That difference we could easily retain if we want - whether it makes sense is a different matter.

Pointing the aliases to something entirely different of course has the potential to break something, but it's either that or those tag names come simply invalid forever.

[pmatilai]

SOURCEPKGID needs to be dealt with along with PKGID because they are linked: SOURCEPKGID of a binary package equals the PKGID of its source package.

To make it all a little more entertaining, SOURCEPKGID is a distinct tag, whereas PKGID and HDRID are just tag aliases. So it indeed seems the only sane way to deal with this is to make PKGID and HDRID extensions that manage the compatibility. And to preserve at least some compatibility, SOURCEPKGID needs to remain binary format, we can use header SHA256 for the data itself in v6 packages, and the PKGID extension then converts SHA256 from hex to binary.
It's a pretty weird mess.

[pmatilai]

Did a draft implementation of the above yesterday and it just doesn't seem right.

If we retain SOURCEPKGID then it should be pointing to another concrete tag in the source package, not some extension thing. Since it needs to be in binary format, then the counterpart needs to be binary too. We could just add header SHA256 as binary to PKGID, which would seem silly and redundant. And mostly harmless, until you realize it'd be visible as SIGMD5 too, which means header+payload MD5 which it certainly would not be at all. So that option seems out too.

I'm starting to think we just need to abandon all these previous ID tags, this mess is does not seem salvageable in any sort of compatible manner.

As an easy way to preserve the link between src.rpm and binaries produced from it, we could add a new SOURCESHA256 tag that just points to the SHA256HEADER of the source package. It's of course again incompatible, but I don't see a way around that, this seems inherintly and irrepairably incompatible all the way, because of the way PKGID and HDRID are aliased to SIGMD5 and SHA1HEADER.

[pmatilai]

Maybe, we could salvage HDRID for this purpose.

Rename the tag pointing to SHA1HEADER to OLDHDRID as per rpm tag renaming tradition (we just haven't done that in ages) so older rpms always get the SHA1 they expect from that tag and nothing for v6 packages, newer rpm's will get SHA256HEADER, and you'd specifically have to ask for the old version instead. Add SOURCEHDRID to match. And just drop the PKGID variants from v6 entirely, we have nothing comparable there anyhow.

In that scheme we could also add HDRID tag extension on top to get the SHA1 if SHA256 isn't there, but I'm not sure it's worth it, all packages since rpm 4.14 have the SHA256 anyhow...