[Bug 195] Review request: perl-Crypt-IDEA - Perl interface to IDEA block cipher

[Michael Schwendt]

On Sun, 18 Jan 2009 16:50:07 +0100, Ralf wrote:

> > It is considered helpful by many package users, because they can judge about
> > the age of documentation files simply by checking timestamps. Particularly
> > helpful with but not limited to larger pdf/ps files and html trees. No need to
> > revisit such files after package updates, if the documentation is still
> > unchanged since 2001, for example, and other files are several months old, too.
> > User would "cd /usr/share/doc/..." and quickly notice that only a README file
> > has changed for this update.
> 
> Provided the fact many pdf/ps/man files are _generated_ (doxygen, 
> texinfo, pod2man), this rationale is of very limited use, as well as a 
> simple "INSTALL=install -p" would not help in many occasions.

*sigh* :) Obviously, and I wonder why I need to point it out then *G*, no
reviewer should ever request "install -p" for files, which are
created/modified as part of the build. It makes no sense to preserve
timestamps, which change at package build-time.

> > I think related to
> > .rpmnew creation of config files just because the mtime changed (and not just
> > the checksum).
> 
> .rpmnew's are being generated for %config files. Handling them correctly 
> is rpm's job. And yes, IIRC, rpm once had been broken wrt. them.

Twisting words (and splitting hairs) doesn't help, though. It is news
to me that we recommend "install -p" as a work-around for bugs in RPM.
I just needed to point out that preserved timestamps have been helpful
also in such a case (e.g. with default %config files installed from
%{SOURCEX} locations).

> > Some reviewers have expanded the recommendation to use "install -p ..." to also
> > run "make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p", which I think
> > is somewhat over the top
> 
> Agreed, but I'd express it a bit harder: Enforcing such a rule 
> demonstrates a reviewer's lack of technical skills.

Which is one reason why I wasn't too simple to come up with the first
official list of ReviewGuidelines IMO. Because several reviewers would
never review anything not mentioned on that list, whereas other people
would take every chance to find exceptions for items where common sense
must be applied during review. The breakup of the list into MUST/SHOULD
items was a compromise AFAIR. Preserving timestamps is not on the
list. It's only loosely connected via the "MUST: The package must meet the
Packaging Guidelines" item, and the guidelines only recommend preserving
timestamps where easily possible (such as when downloading tarballs).
It really doesn't add much other than telling a bit about the age of
some files -- in other cases even the timestamp of downloaded tarballs
is inaccurate.

Nowadays, though, the focus is on metrics and who does the most reviews.
The ReviewGuidelines are no longer seen as a minimum list of what to
consider. They have lead to a "NEED NOT care about anything else"
situation. And that's also why we have problems with broken deps,
missing obsoletes, sub-packages being toggled on/off randomly,
and similar problems.

> E.g. perl modules typically copy around their sources (lib/blib) during 
> builds, generate man-pages on the-ply (using pod2man) etc.

Historically, "install -p" (or "cp -p") was only suggested for stuff
copied directly in the %install section, such as %SOURCEX files and
prebuilt files not installed by make install. The %doc files also preserve
timestamps, for example.