search

rpm-rs / rpm

Other
47 stars 26 forks source link

Exposing "write" for PackageMetadata publicly #216

Closed mstg closed 9 months ago

mstg commented 9 months ago

Hi folks,

Was exploring this library for a personal project where the RPM headers are more of an interest than the full RPM. There is currently a public method for parsing header only but the write one is marked "pub(crate)". Would it be of interest to make this "pub"?

I can PR if changing it wouldn't be too much trouble.

Thanks

dralley commented 9 months ago

It certainly wouldn't be an issue, the reason it's private is simply that there was no obvious use case and so we leaned towards minimalism.

I am curious about the use case though, you're planning to write out some RPM headers divorced from the actual payload?

mstg commented 9 months ago

Thanks for a quick reply @dralley! Yes, it is related to an experimental yum server, where headers are stored separately for rapid indexing. I've created #217

dralley commented 9 months ago

Something along the lines of Pulp?

For the metadata portion, I have another library https://github.com/dralley/rpmrepo_metadata, it's not 100% polished but it might be a nice starting point.

mstg commented 9 months ago

Yes! I'm currently experimenting with new storage backends that doesn't rely on NFS. I'm the author of yumrepofs but it's very slow and very error prone as I didn't have as much RPM/Yum knowledge when I first started working on it. It currently doesn't require files on disk (RPMs are in S3 and doesn't need to be present) but the update mechanism relies on in-place updates with unoptimized algorithms so a single update is still close to 3-5 minutes.

Running experiments with Go (and Rust for the learning experience) to get close to update speeds of 1-3 seconds for RPMs and modules (module update speed of yumrepofs is especially very slow). Your libraries are very much life savers at this point as I'm not very well versed in Rust and are exactly what I need.