Enhance rpm2archive(8) to support cpio format too
#2758
Merged
Conversation
This file contains hidden or 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
pmatilai
force-pushed
the
cpio-obs
branch
2 times, most recently
from
6733d12 to
41ae1fc
Compare
No actual change, just allows more comprehensive testing, easier to read and add more.
runroot is the wrong thing to use with rpm2cpio which doesn't understand things like --define. This has only worked because rpm2cpio is dumb enough not to look at its arguments at all.
Take advantage of rpmfiStat() and archive_entry_copy_stat() which handle most of the dirty work here. Hardlink sizes are special because in archives, the file size is 0 except for the one with the content, but otherwise of course hardlinked files have sizes as usual.
cpio is a legacy format but content in that format will remain with us for a very, very, very long time still. Better support the format here than have to support a separate tool just for the purpose. The "new ascii cpio" format can't host files larger than 4GB, but most rpm content fits and will continue to do so in that range easily, so instead of just outlawing the good 'ole format, just skip over anything we can't handle and emit a warning. Additionally, if invoked as "rpm2cpio", behave like it: no compression, cpio format.
Do all the entry fillup in the function intended for that, no functional changes intended. Drop the unnecessary nlink check from the unpacking: if there's content, it should unpacked.
Now that rpm2archive knows how to impersonate rpm2cpio when called by that name, we can just drop the latter entirely. The one notable behavior change is src.rpm contents now getting ./ prepended to the paths. We could fixup for that too, but there's doesn't seem to be any reason to bother. It's crucial that we start steering people away from rpm2cpio because it wont be able to deal with v6 content. cpio is obsolete even in POSIX now.
dmnks
reviewed
Nov 10, 2023
dmnks
approved these changes
Nov 10, 2023
| @@ -237,6 +273,12 @@ int main(int argc, const char *argv[]) | |||
|
|
|||
| optCon = poptGetContext(NULL, argc, argv, optionsTable, 0); | |||
| poptSetOtherOptionHelp(optCon, "[OPTIONS]* <FILES>"); | |||
|
|
|||
| if (rstreq(basename(argv[0]), "rpm2cpio")) { | |||
|
Okay, I guess we'll just merge then. Thanks for the eyeballs 😄 |
dmnks
changed the title
dmnks
changed the title
rpm2archive(8) to support cpio format too
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.
Enhance rpm2archive to support cpio format too, replace rpm2cpio with it entirely.
This is important as rpm2cpio can't deal with 64bit file sizes which will be the norm in v6.
For details, see the commit messages.