please reference prior art and learn from it

[cgwalters]

Presumably, this project was motivated by rpm-software-management/dnf5#833 ? There's a lot of prior art noted in that ticket. It'd be good if this project at least noted that and seemed to have made some effort to analyze those prior things for their positives/negatives.

For instance, I notice this one includes the URL. This ruins "git diff" when one is using datestamped composes: konflux-ci/rpm-lockfile-prototype#18

Also, in rpm-ostree's lockfile as used by fedora-coreos-config we ended up splitting each architecture into a separate file. Notice how much simpler the lockfile there is.

Unrelated to the above:

checksum: md5:1254011a2ce1245f0b528b1190fa3cb6

md5??? I'm guessing someone just wrote the example as a strawman of the YAML format, but please since you're creating something new don't even try to support md5.

[praiskup]

For instance, I notice this one includes the URL. This ruins "git diff"

I agree that including the full URL for every component would unnecessarily
bloat the lockfiles. Using a repo URL combined with a relative location
would likely cover most use cases. But for Mock which frequently works with
mirrored content. I filled #7.

[mcurlej]

Also, in rpm-ostree's lockfile as used by fedora-coreos-config we ended up splitting each architecture into a separate file. Notice how much simpler the lockfile there is.

To have all the architectures in one file was a requirement. But i am not opposed to have a switch which could do that.

[jan-kolarik]

Hi Colin,

Presumably, this project was motivated by rpm-software-management/dnf5#833 ? There's a lot of prior art noted in that ticket. It'd be good if this project at least noted that and seemed to have made some effort to analyze those prior things for their positives/negatives.

Well, kind of. While addressing the issues in rpm-software-management/dnf5#833 is not the primary objective of this project, we aim to incorporate the key considerations mentioned there. If there is a strong demand, we are open to extending the current solution. It appears there are several stakeholders involved, so we're starting with an MVP that covers basic functionality for all of them.

For instance, I notice this one includes the URL. This ruins "git diff" when one is using datestamped composes: konflux-ci/rpm-lockfile-prototype#18

Thanks, that's a good point. I’ve tried to address this in the existing #12.

Also, in rpm-ostree's lockfile as used by fedora-coreos-config we ended up splitting each architecture into a separate file. Notice how much simpler the lockfile there is.

Currently, the main request was to use a single file. However, adding support for generating separate manifests per architecture could be easily implemented in the dnf plugin, which serves as a client for this library.

md5??? I'm guessing someone just wrote the example as a strawman of the YAML format, but please since you're creating something new don't even try to support md5.

Yes, this was only intended as an example. I definitely understand that md5 is deprecated, but since it’s still supported by dnf and rpm, it's just included to ensure compatibility. The support here simply means that the manifest file can accept the md5 value in case it shows up unexpectedly from a wild third-party repo. 🙂