Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=505155
--- Comment #4 from Jussi Lehtola <jussi.lehtola(a)iki.fi> 2009-06-11 08:53:51 EDT
---
(In reply to comment #3)
wrt to comment #1 item 1, power supply on that server burned up and
hasn't been
replaced. Updated the spec file to point to my people page for now. Items 2-4
are also fixed. For item 5, all example rpms that I looked at have the .so file
in /lib64 if the library is there also. Is there a guideline that says this is
wrong or something bad that will happen if I don't? IOW, what are the problems
caused by leaving it in /lib64?
That's not a standard location according to FHS. You have been looking only at
some core utilities spec files, everything else installs the libraries in
%{_libdir}. Using %{_lib} for anything else is forbidden.
wrt to comment #2 item 1, No. Item 2 is fixed. Item 3, I like
explicit
attributes so that when I look at the specfile I know exactly how everything is
going to land just in case there is a mistake in the make files. (I can point
to bz on the prelude stack where explicit perms would have prevented doing
security errata.)
But the normal umasks set by the build environment are fine.
Item 5, I don't see any spec files doing this. Why would
build-time timestamps be important? I can see the reason for multilib timestamp
coordination for shared resources, but why would I need to do this?
http://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps
It's a guideline and thus mandatory. Files that aren't generated in the build
(e.g. the header file) need to keep their time stamps. This package will also
be multilib, won't it?
Thanks for the review comments. I posted a new spec file to the same
place as
above, but won't update the srpm until later today after I put some man pages
in the tarball and do an official release.
You didn't increment the release, which you should do whenever making
revisions.
--
Configure bugmail:
https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.