Those files are added in the extra files phase. I agree it should be tracked in some metadata.

Do you have any suggestions on the format? We need to keep in mind Pungi has no idea what files actually are, so the metadata will not be very descriptive.

It could be something as simple as a CSV file in the root of the repository that includes the relative path to the file, a checksum string (something like "<checksumtype>:<checksum>"), and maybe a file size. On the other hand, it could be added to the treeinfo file as new entries in the [checksum] section to avoid adding yet another metadata file.

I think it would be nice to allow the user to define a bit of optional metadata to go with each file (maybe just a string tag, maybe a set of key-value pairs). That way things could be tagged as "documentation" or "gpg" or something and can be neatly sorted into buckets by tools like Pulp. Maybe that's outside the scope of this issue, or maybe it's best to do them all at once.

As a side note, once we decide what exactly we all want to do, I can probably find the time to do the work and make a PR, if everyone is willing to put up with my questions while I do so :)

Hey, I made a first pass at this here: https://pagure.io/fork/jcline/pungi/commits/extra-files-metadata

I built it on top of your test-extra-files branch, and two unit tests were failing. There are a couple new tests failing from my patch, but I wanted someone to have a look before I invested too much time in a direction we may not want to go.

The one thing I'm considering adding to the metadata structure (described in the latest commit message on the above branch) is a version or something similiar, in case the schema changes later. Any thoughts on that?

Generally it looks good to me. Would you mind opening a pull request? That would let us add comments to specific lines.

I agree having a version number in the file would be useful. Maybe the file could be more aligned with what productmd does: a header with version (and possibly file type) and a payloadsection with the actual data.

I'm not sure why the checksum is stored like it is: wouldn't it be easier to process if the type was separated from the checksum itself? This is how checksums are stored in image metadata.

Thanks for the feedback! I've made a PR. It's based on your metadata branch so it's pulling those commits in as well, unfortunately. I also changed the checksum to match the image metadata.