Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

First batch of v6 package format #3017

Merged
merged 9 commits into from Apr 4, 2024

Conversation

pmatilai
Copy link
Member

@pmatilai pmatilai commented Apr 4, 2024

Here we go. Details in commits, and this is obviously nowhere near complete, the v6 work will be ongoing throughout the year.

There's nothing new here per-se, both the doc draft and the patches have been up here as drafts before. Just the digests changing due to version bumps, making rebasing this pretty annoying 馃槄

This may seem silly but it allows the test diffs to highlight the actual
changes, making it easier to verify each change.
Add %_rpmfilever macro to control which format we create, with
experimental disclaimer: the v6 spec hasn't been finalized yet, this
is merely the beginning of the implementation for the parts we know
already:

Obsolete crypto (MD5 and SHA1) tags and the unreliable size tags in the
signature header are dropped.
The multitude of size tags in the v4 signature header are effectively
useless because they're unsigned and so entirely untrustworthy. Having
a reliable size available seems like a potentially useful thing to have,
so lets yet another set of size tags, but this time in the main header
like the payload digests. And like with the digests, have one for the
compressed and alt-version for the uncompressed size.

Unlike the payload digests, this is only in v6 to avoid introducing
what is technically an v4 incompatibility due the int64 type.
While this is neither a signature or digest, having the size tested next
to the digests seems useful. The reproducability test doesn't use
compression so both sizes are equal.
Switching to the long tags implicitly changes to the "new" payload
format which in v4 was used only for packages with >= 4GB files.
It's noteworthy how much smaller the payload is: the new format has
much less overhead due to not carrying duplicate metadata.

Also noteworthy is that we still cannot change the name of the payload
format stored in the header, as doing so would cause a gratuitous
incompatibility with rpm >= 4.12 which can handle the payload format
just fine. So rpmlib(LargeFiles) dependency remains the means to track
the actual payload - as an acute observer will note, the number of
dependencies in the dump grows by one.
Unfortunately RPMSIGTAG_RESERVEDSPACE clashes with RPMTAG_INSTALLTIME
so we can't use it in v6. Introduce a new tag at the top of the
signature range to make sure its always the last one - on v6 packages
that is. For v4 packages we're better off not messing with the existing
tag at this point, we just need to handle both.
It'd be harmless as v4 too, but adding it there serves no real purpose
at this point and probably only complicates any logic to figure out a
package version. With this, any package without that tag is not v6.
The only thing that looks at these fields is "file", and even that would
be better off not doing so because the canonical numbers are so
meaningless: i386/x86_64 is the same thing, right?
Because rpm 4.x widely checks for the version in the lead to be either
3 or 4, bumping it to 6 would cause a total compatibility break for
a value that is otherwise entirely unused in rpm. Which makes no sense
whatsoever.

As v3 and v4 used 3 as the major format (presumably for LSB
compatibility reasons), we can at least bump it up to 4 for v6 to
differentiate. It's not such a big lie as v6 uses the same fundamental
structures as v4. For v7 we should be able to bump this up to the
matching number...
@pmatilai pmatilai merged commit cf1c521 into rpm-software-management:master Apr 4, 2024
1 check passed
@pmatilai pmatilai deleted the v6-pr branch April 4, 2024 10:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant