http://bugzilla.rpmfusion.org/show_bug.cgi?id=195 rc040203(a)freenet.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rc040203(a)freenet.de --- Comment #2 from rc040203(a)freenet.de 2009-01-17 05:29:54 --- (In reply to comment #1) Wrong. / is mandatory on sed "deletes". These are common Fedora perl packaging standards, you should be familiar with. Superfluous - It's an urban legend that this would fix anything. Correct ... SHOULD. Almost. Your final conclusion is right (these dirs must be owned), but your explanation is not quite right. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=195 --- Comment #4 from Kevin Kofler <kevin.kofler(a)chello.at&gt; 2009-01-17 19:35:54 --- It's a MUST in the Fedora guidelines. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=195 --- Comment #6 from Kevin Kofler <kevin.kofler(a)chello.at&gt; 2009-01-18 06:24:10 --- No, it reflects older versions of RPM (which are probably still in use at least in older RHEL releases) which treated files with different timestamps as different, causing multilib conflicts. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=195 Conrad Meyer <konrad(a)tylerc.org&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |konrad(a)tylerc.org --- Comment #8 from Conrad Meyer <konrad(a)tylerc.org&gt; 2009-01-18 06:40:12 --- Older RHEL releases don't have multilib anyways, which makes this not a problem (I guess). -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=195 --- Comment #10 from Michael Schwendt <mschwendt(a)gmail.com&gt; 2009-01-18 12:49:21 --- The original rationale for recommending "install -p" and "cp -p" when installing files manually (inside the spec file e.g.) has been in preserving timestamps for _prebuilt_ files in tarballs. Such as various forms of documentation files. 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. A few corner-cases have been found where install -p helped, I think related to .rpmnew creation of config files just because the mtime changed (and not just the checksum). Perhaps some have been only temporary. 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 even if covers a few more prebuilt files. Some tarballs mix cp/install and mkdir/install, so one would need to switch to "cp -p" for the full show. So, conclusively: Historically it has only been pedantic eye-candy (albeit considered helpful by our users). If nowadays there is knowledge that it actually fixes anything else, please document that. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

On Sun, 18 Jan 2009 16:50:07 +0100, Ralf wrote: *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. 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). 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. 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.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=195 --- Comment #12 from Kevin Kofler <kevin.kofler(a)chello.at&gt; 2009-01-19 00:57:27 --- CMake appears to get this right, stuff installed with INSTALL(FILES ...) in CMake gets installed with the timestamp in the tarball. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=195 --- Comment #14 from Paul Howarth <paul(a)city-fan.org&gt; 2009-01-21 14:26:34 --- (In reply to comment #1) Done. I added a comment about the sed command. The other commands are all basically idioms found in all perl modules (see the perl spec template from the rpmdevtools package) relating to packaging perl modules sensibly in rpm format without having them all conflict with each other - the removed files aren't needed in rpm-based distributions. We don't want to add identical commentary to hundreds (thousands?) of perl module packages,do we? This is already done with the exception of IDEA.pm, and the Crypt::IDEA manpage, which is derived from IDEA.pm. The IDEA.pm is edited in %prep and I don't think it's appropriate to fiddle the timestamp of the edited file to be the same as the original one. Done. The guideline about directory ownership basically states that a package should own all directories that it uses that are not already owned by by any of its dependency packages. It is very common amongst perl modules for unrelated (i.e. no dependency relationship) packages to own the same directories because of the directory hierarchy used for perl module install paths, e.g. all architecture-specific perl-Crypt-* packages will own {perl_vendorarch}/Crypt/ unless they depend on another perl-Crypt-* package. crypto-utils is in fact such a perl package but it doesn't follow the usual perl package naming format. Since perl-Crypt-IDEA does not have a dependency on any other package owning these directories, it's correct that it owns them itself. Updated package: Spec URL: http://www.city-fan.org/~paul/extras/perl-Crypt-IDEA/perl-Crypt-IDEA.spec SRPM URL: http://www.city-fan.org/~paul/extras/perl-Crypt-IDEA/perl-Crypt-IDEA-1.08... -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=195 Paul Howarth <paul(a)city-fan.org&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |33 --- Comment #16 from Paul Howarth <paul(a)city-fan.org&gt; 2009-01-22 11:53:18 --- Package CVS request ====================== Package Name: perl-Crypt-IDEA Short Description: Perl interface to IDEA block cipher Owners: pghmcfc Branches: F-9 F-10 EL-5 InitialCC: ---------------------- License tag: free -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=195 Paul Howarth <paul(a)city-fan.org&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #18 from Paul Howarth <paul(a)city-fan.org&gt; 2009-01-22 13:03:21 --- All branches built successfully. Thanks everyone. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=195 Nicolas Chauvet <kwizart(a)gmail.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|33 | -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.