Re: Corner cases for -kmod-common packages
Philip Prindeville wrote:
This is a variant of that scenario. If the version number of the rpm
has
changed (as well as the timestamp), but the content manifest and hash of
the contents themselves remains identical, rpm should not update the
package.
Changing RPM would achieve almost nothing: Updating the package on disk
isn't the expensive part, downloading it (and getting needlessly prompted by
the updater!) is. You would also need to change yum (and zif) there, which
also includes changing the repository metadata backwards-incompatibly,
because there's no metadata for a checksum covering package contents only
(without the RPM header). So yum shouldn't prompt you for the useless
update, but it will need to change the version recorded in the RPM database
in case there are RPM dependencies on the new version, so it'd silently
change the RPM database, which opens a HUGE can of worms. Things aren't as
easy and straightforward as you seem to think…
It's more of a tooling issue as I see it than an organizational
requirement on how the .spec should be managed.
I'd rather fix the tool than work around it.
Sorry, but you have to expect that RPM and yum will NEVER be changed the way
you ask. You need to work with what's there. That's what guidelines are for.
I don't see how a specfile you basically never have to touch, and which got
reviewed and approved in one go along with the other one, is a burden in any
way.
Kevin Kofler