Stop store content in memory for RPMBuilder

[ikrivosheev]

PR Content Desc

At the moment, RPMPackage store content in memory. This is not good situation. I rewrite RPMPackage to generic struct.

If my idea is ok for maintainers, I will finish the PR.

• 🦚 Feature
• 📙 Documentation
• 🦣 Legacy
• 🪣 Misc

Closes #

Changes proposed by this PR

Notes to reviewer

📜 Checklist

• Test coverage is excellent and passes
• Works when tests are run --all-features enabled
• Documentation is thorough

[dralley]

Is this roughly equivalent to what #6 is describing?

Without having looked deeply at the PR yet, I think it makes sense to read the payload on-demand, but not necessarily the headers. Headers usually quite small and don't require a lot of memory to store. Doing many small reads is also less efficient than doing a small number of larger (~=8mb) reads.

[dralley]

I'm going to try to take a step in the right direction with a PR to address #107

A general complication is that

• you have to generate the payload in order to calculate a checksum of the payload
• you have the calculate a checksum of the payload in order to put that checksum in the header (also other attributes like the size of the payload)
• you have to have a completed header before you can assemble and sign the package

So the first step is just going to be to avoid storing everything twice, once independently in the list of file entries to be processed, and once in the contents of the payload.

[ikrivosheev]

Well, good news) Some tests work now)

[ikrivosheev]

@dralley hello! Can you review PR and say your thoughts about my PR. Does it make sense to complete it?

[dralley]

I would hold off on continuing this for the time being. I think there are some interesting ideas here, but I'm not sure about the implementation. There are a couple of bigger problems to address first when it comes to builder memory use, and on the reading side, the introduction of RPMPackageMetadata mostly handles with that problem.