Multiarch conflicts on devel packages with %doc files

[Michael Schwendt]

On Sun, 21 Oct 2007 14:02:00 +0200, Ralf Corsepius wrote:

> > > > ...and from elsewhere in the thread, unless you install carefully
> > > > (install -p) it's not just generated files that'll mismatch but even
> > > > header files that were copied into a devel rpm.
> > > Well, my view is converse: "install -p" doesn't solve anything, because
> > > it doesn't work on generated files.
> > 
> > Right. Originally, the reason why "install -p" and "cp -p" have made
> > it into pkg review comments is only that _old_ files from tarballs (or
> > additional SourceX tags) stay _old_ when copying them into the rpm
> > buildroot -- i.e. their old timestamps are preserved. That way the pkg
> > users
> ^^^^^^^ => It's just convenience to cater certain user habits. 
> 
> Technically, it's sense-free eye-candy.

I don't disagree.

Except that I see the value in preserving [old!] timestamps as explained
in the prev.msg.

> >  can see the age of files more easily and see when a file has
> > been updated last.
> 
> >  There is a relevant use-case for %doc and %config
> > at least.
> How? %doc are completely irrelevant to an installed system,

Why?

> for %config
> it's contents that matters (did the files contents change?), not
> timestamps.

Yes, sure, but for changed contents we have the *.rpmnew/*.rpmsave
mechanism already. For config file templates, default config files or
[init]scripts we don't. Why pretend that a config file (or a file added
via SourceX) is from 2007-10-21 when in fact it has not been changed
for several years? Such a superfluous change in the timestamps also
can result in an unneeded IDS report everytime a pkg is updated.