Corner cases for -kmod-common packages

[Kevin Kofler]

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