[Rpm-maint] [rpm-software-management/rpm] Discussion: Understanding the Ecosystem Impact of RPM v6 on Repository Metadata and Client Behavior (Discussion #3968)

[Panu Matilainen]

AFAICS the repodata does not include any info at all that would change because of v4/v6. Overall, assuming even a remotely recent rpm version, you just don't need to care a whole lot about v4/v6, that was a design goal. See https://rpm.org/releases/6.0.0#compatibility-notes.

Of course the devil is in the details, in particular assumptions in tools that intimately work with rpms that no longer hold. createrepo_c appears to rely on some legacy data when --cachedir is used: RPMTAG_SHA1HEADER is not present in v6 packages, and neither are RPMTAG_SIGGPG or RPMTAG_SIGPGP. The latter two are v3 signatures that were long deprecated even in 2014 when their use was introduced there, rpm stopped creating them for even v4 packages a few years ago. So createrepo_c's --cachedir option is probably somewhat broken already, and more so with v6 packages. Similarly, libsolv might need some tweaks, I know some have already been done.

Multiple signatures is something that will affect the client-side tooling, eg the traditional yum/dnf .repo config format suggests one key per repository, which is not a safe assumption even with v4 packages. 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3968#discussioncomment-14549608
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/repo-discussions/3968/comments/14549608 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20250930/e06b47f5/attachment.htm>