Corner cases for -kmod-common packages

[Philip Prindeville]

On 1/26/12 12:43 AM, Kevin Kofler wrote:
> Philip Prindeville wrote:
>> In the case of a trivial (and invariant!) -kmod-common file, should we be
>> allowed to keep everything in a single .spec?
> 
> That would mean the package gets needlessly updated each time the kmod is 
> rebuilt from a new kernel, even though it never changed at all. So that's 
> exactly the reason why a separate specfile and SRPM is needed!
> 
>         Kevin Kofler
> 

Yeah, but this is an artifact of rpm/yum and indeed a previous issue: when you built a library (for instance) as both x86_64 and i686 binaries on Fedora 16, the first one installed might create a yyy.conf file and then when rpm tried to install the same file again (but with a slightly different timestamp as they would have been built sequentially) rpm would assume that the file had been modified and leave you both an xxx.conf file and a yyy.conf.rpmnew file.

This was eventually fixed in rpm so that the size, modes, and hash of the contents were used, but the timestamp was ignored.

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.

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.

-Philip