[Bug 505155] Review Request: libcap-ng - An alternative posix capabilities library

[bugzilla at redhat.com]

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 at redhat.com>  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.