On Wed, Nov 12, Stephan Kulow wrote:
On 12.11.2014 09:57, Olaf Hering wrote:
I wonder why its important to republish a package which just had a new commit. If the resulting binary package is identical there is no need to republish, just because the rpm %RELEASE string happens to differ.
The list of checked tags is not complete and so you never know what the commit was about.
If the source changed there is some URL in some tag. The release itself looks meaningless. But there are likely packages that rely on a certain release number.
Similar for a new rpm version in the build tree. Why would that require a republish of the entire tree? I mean the install stack has to cope with old rpm packages anyway, no matter which version of rpm was used to create these packages.
We don't test all header values so you just don't know if the rpm is complete or not. And to avoid that problem we flush the build-compare for new rpm versions.
What do you mean with "if the rpm is complete"? There is an existing package, and its fine and usable. If the new rpm does something new to a package, who cares? If its important a to-be-added check in build-compare may catch it.
I think you're overoptimizing.
Just trying to reduce the noise. Olaf -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org