On 23 December 2016 at 21:02, Anton Marchukov <amarc...@redhat.com> wrote: > Hello Barak. > > But why this should be handled on infra side? Was that infra code that > produced two RPMs with same name and version and different content? If not > then I would bug it against whoever code is creating such RPMs and it then > should be rebuild with at least rpm release incremented and hence does not > require cache invalidation.
I did not query Sandro about why he did the update the way he did. He knows far more then I do about the various build processes of the various packages and oVirt, an I tend to trust his judgement. > Any reason we are not doing that? This can take time, every maintainer has his own (bad) habits, and not everyone will agree to do what we want (Some downright regard oVirt as a "downstream" consumer and refuse to do anything that they regard as oVirt-specific!). In the meantime we need to be resilient to such issues if we can. We can`t just let everything fail while we try to "fix the world". Also, next time around, we could be seeing similar caching issues with a non-yum/rpm file, so its good to have a deep understanding of the data paths into our system. -- Barak Korren bkor...@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra