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 #3 from Steve Grubb <sgrubb@xxxxxxxxxx> 2009-06-11 08:39:31 EDT --- 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? 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.) 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? 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. -- 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review