Unify file-related information under FileEntry (get_file_entries)

[marxin]

Support all file-related functions for a case where an RPM is free of files.

[dralley]

We have an "empty" rpm with no files here, I'd prefer if you used that instead of adding a new one

[dralley]

Also, I would kind of prefer to delete these methods entirely, and just make sure their functionality is present via get_file_entries(). I don't see much point in getting a list of file checksums or signatures without having access to either the contents or at least the path of the file, and making the user join them back together manually wouldn't be great API.

[marxin]

We have an "empty" rpm with no files here, I'd prefer if you used that instead of adding a new one

Thanks, I've just done that.

[marxin]

I don't see much point in getting a list of file checksums or signatures without having access to either the contents or at least the path of the file, and making the user join them back together manually wouldn't be great API.

Yes, I also agree with the suggested approach. The only small drawback of the get_file_entries approach is that you need to parse many RPM Tag sections before you can assemble a FileEntry.

[dralley]

Yes, I also agree with the suggested approach. The only small drawback of the get_file_entries approach is that you need to parse many RPM Tag sections before you can assemble a FileEntry.

What do you mean? The whole header is "parsed" up-front. This function does clone a few values, and the timestamps and digests have a little bit of parsing, but I don't think it's particularly expensive.

Ultimately it's not that difficult to fall back to fetching the tags directly if get_file_entries() isn't sufficient for some reason.

[marxin]

What do you mean? The whole header is "parsed" up-front.

Ah, ok, that's what I mean. So if it's parsed, then it's fine. If you want, I can prepare yet another pull request where I'll unify all under the umbrella of get_file_entries function.

[marxin]

The question is if you want to do it instead of this PR, or after that. What do you prefer?

[dralley]

You can use this PR

[dralley]

note to self: I really ought to finish my own PR that will allow fetching the contents of file entries out of the archive

[marxin]

Do you want to omit the get_file_paths function from the public API?

[dralley]

That one I think could potentially be useful on its own (and isn't trivial to implement) so it should probably stay.

[dralley]

This looks great, thanks!