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
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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...
This was referenced Apr 4, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 馃槄