[Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)

[Ludwig Nussel]

> The file order in payload doesn't match the one in the header, at least for hardlinks and other stuff that may not have content at all. Maybe in a perfect world one could expect that order to be strictly defined and always correct, but there are multiple cases in rpm history where one bug or the other has led into order changing or things like %ghost payload in the header where it's not expected. So I for one will sleep a lot better knowing there's a mapping from payload to the header.

The point would be to not allow arbitrary ordering anymore. If if the payload is a raw data area, there is no way to deviate from the header. So instead of allowing to refer back and forth between payload and header we only allow pointing from the header into the payload. The rules are rather simple:
- the order of file data is the same order as those of the file related arrays
- offset and length of the data for each file are calculated based based on the `FILESIZES` array
- skip non regular files (`FILEMODES`)
- skip ghost files aka the marker that the payload does not contain the file's data (`FILEFLAGS`)
- each unique inode only once aka don't duplicate hardlinked data (`FILEINODES`)

If at the same time we restrict `FILEINODES`  to numbers from 0 to max nfiles-1, then no extra inode search/lookup would be needed either.

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

Message ID: <rpm-software-management/rpm/repo-discussions/2374/comments/4830063 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20230131/fc8d5a5d/attachment.html>