Description of problem: During development I do not bump the version or release numbers because they are not really "published". All successful builds are included in the repository listing. Yum is unable to find the latest one and probably pick the first found, which results in being unable to install the latest build. Dnf is handling this situation much better. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. build your package with version+release numbers 2. rebuild it with changes but same version+release numbers Actual results: yum installs the wrong package. Expected results: yum install the package from the latest successful build. Additional info: Having all built RPMs available in the repository is very nice and should probably not be changed, as you can always download it manually. Nevertheless in the repository listing, for the same exact version+release numbers there should be only one entry, corresponding to the latest successful build.
Hello, this concerns yum repodata format and createrepo/createrepo_c utilities and their way of creating repodata. And then also yum tool that wasn't able to download the latest version of a package. I think having all built packages in repodata is okay. You might want to experiment with two or more versions of the same package in one project or sometimes you find out the the just installed newest version contains a bug and you want to downgrade quickly. For these cases, it's good to keep also older package versions (at least for a limited amount time).
Thanks for your reply. Do you know since which version yum is behaving properly? I understand and I agree it can be useful to keep older package. How can we define how many to keep? I never saw such setting and it would be better if we could restrict it in order to avoid eating huge Copr resources uselessly (at least in my case keeping the latest failed for investigation and the 2-3 latest successful would be quite enough).
> Do you know since which version yum is behaving properly? No, not really. If you have a reproducer, we can study it into more depth. > I understand and I agree it can be useful to keep older package. How can we define how many to keep? I never saw such setting and it would be better if we could restrict it in order to avoid eating huge Copr resources uselessly (at least in my case keeping the latest failed for investigation and the 2-3 latest successful would be quite enough). It is set as a constant - same for all projects. Only the latest version of a package is guaranteed to be kept. The older versions of a package are deleted if they are older than 14 days. We have an issue filed here for it: https://bugzilla.redhat.com/show_bug.cgi?id=1373568, but for simplicity I think it is beneficial that it is a constant. The auto-deletion is described here https://docs.pagure.org/copr.copr/user_documentation.html#how-long-do-you-keep-the-builds, by the way. Sorry for the late response here. I noticed the response today.
Thanks for the doc pointers. My reproducer case expired as it is much older than 14 days :-). I'll ping again here if I can reproduce it in the future.