Bug 505155 - Review Request: libcap-ng - An alternative posix capabilities library
Review Request: libcap-ng - An alternative posix capabilities library
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-10 16:24 EDT by Steve Grubb
Modified: 2009-06-12 13:24 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-12 13:24:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tmraz: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Steve Grubb 2009-06-10 16:24:06 EDT
Spec URL: http://people.redhat.com/sgrubb/libcap-ng/libcap-ng.spec
SRPM URL: http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-0.4-1.src.rpm
Description: Libcap-ng is a library that makes using posix capabilities easier and provides utilities to analyze your system for privileged apps.
Comment 1 Tomas Mraz 2009-06-11 04:49:49 EDT
1. www.web-insights.net does not resolve for me.

2. There is no URL on Source0.

3. The COPYING file is GPLv2 but the library sources are LGPLv2.1+. As you're the upstream, please add also the LGPLv2.1 text in the original tarball.

4. There is missing rm -rf $RPM_BUILD_ROOT on the beginning of %install.

5. The symlink libcap-ng.so in the -devel subpackage should be in %{_libdir} not /%{_lib}/

rpmlint is silent:

$ rpmlint -v libcap-ng-0.4-1.x86_64.rpm 
libcap-ng.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-debuginfo-0.4-1.x86_64.rpm 
libcap-ng-debuginfo.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-devel-0.4-1.x86_64.rpm 
libcap-ng-devel.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-0.4-1.src.rpm 
libcap-ng.src: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-utils-0.4-1.x86_64.rpm 
libcap-ng-utils.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
Comment 2 Susi Lehtola 2009-06-11 06:39:10 EDT
A couple of notes:

- Doesn't
 %configure --disable-static
disable building the static library?

- Normally, you don't need to
 mkdir -p $RPM_BUILD_ROOT/%{_mandir}/{man3,man8}
 mkdir -p $RPM_BUILD_ROOT/%{_lib}
as make install will do this for you. Also, you need to
 rm -rf $RPM_BUILD_ROOT
at the beginning of %install.

- You shouldn't need to define attributes in %files. If the attributes are not correct, the Makefile should be adjusted to give 644 for normal files and 755 for libraries and binaries (or set the attributes using chmod in %install).

- Time stamps are not preserved, use
 make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"
Comment 3 Steve Grubb 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.
Comment 4 Susi Lehtola 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.
Comment 5 Tomas Mraz 2009-06-11 08:57:19 EDT
In the new spec there is a typo in Source0 URL and extra space at the end of the %configure line.
Comment 6 Tomas Mraz 2009-06-11 09:01:26 EDT
Jussi, note that the version is bumped so release doesn't have to be.

And the library itself should stay in  /lib{64,} because the system core utilities will depend on it. The question is only about the devel symlink.

Also the timestamps guideline is not a strict guideline - note the 'consider' word in the guideline and so on.
Comment 7 Susi Lehtola 2009-06-11 09:25:48 EDT
(In reply to comment #6)
> Jussi, note that the version is bumped so release doesn't have to be.

OK, I hadn't noticed that.

> And the library itself should stay in  /lib{64,} because the system core
> utilities will depend on it. The question is only about the devel symlink.

Okay, in that case, my bad. However, Tomas is right; there are quite a few .so files in %{_lib}.

> Also the timestamps guideline is not a strict guideline - note the 'consider'
> word in the guideline and so on.  

Yes, but it's trivial and doesn't hurt anything to keep them.
Comment 8 Susi Lehtola 2009-06-11 09:29:11 EDT
Oh, the permission lines
 %defattr(-,root,root)
should AFAIK be
 %defattr(-,root,root,-)
as per http://fedoraproject.org/wiki/Packaging/Guidelines#File_Permissions
Comment 9 Steve Grubb 2009-06-11 10:58:54 EDT
ok, new spec file uploaded to same place. Wrt to timestamp issue, the suggested fix doesn't work. The symlink was moved. The typos are fixed.
Comment 10 Steve Grubb 2009-06-11 14:46:22 EDT
New srpm has been uploaded to:

http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-0.4.1-1.src.rpm

Please let me know if there are any other issues.
Comment 11 Tomas Mraz 2009-06-11 15:23:12 EDT
I have only two nitpicks:

1. the script to create the new symlink is overly complicated why not do it this way:
rm -f $RPM_BUILD_ROOT/%{_lib}/%{name}.so
mkdir -p $RPM_BUILD_ROOT/%{_libdir}
VLIBNAME=$(ls $RPM_BUILD_ROOT/%{_lib}/%{name}.so.*.*.*)
LIBNAME=$(basename $VLIBNAME)
ln -s ../../%{_lib}/$LIBNAME $RPM_BUILD_ROOT/%{_libdir}/%{name}.so

2. there is unnecessary / before %{_libdir} on the symlink line in %files devel.

The rpmlint is still silent:

$ rpmlint -v libcap-ng-0.4.1-1.x86_64.rpm 
libcap-ng.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-debuginfo-0.4.1-1.x86_64.rpm 
libcap-ng-debuginfo.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-devel-0.4.1-1.x86_64.rpm 
libcap-ng-devel.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-0.4.1-1.src.rpm 
libcap-ng.src: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-utils-0.4.1-1.x86_64.rpm 
libcap-ng-utils.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.  

The nitpicks are no showstoppers so the package is ACCEPTED.
Comment 12 Steve Grubb 2009-06-11 17:08:00 EDT
In response to comment #11, I can remove the '/' from %{_libdir} even though it hurts nothing. 

But wrt to item 1, the only complication is that its saving the cwd and using it later. Its impossible to make a relative link without being in the directory so that the kernel sees both ends connected. You cannot make an absolute link since this is in the build root. So, I have updated the spec file with only the libdir fix.
Comment 13 Susi Lehtola 2009-06-11 17:24:41 EDT
(In reply to comment #12)
> But wrt to item 1, the only complication is that its saving the cwd and using
> it later. Its impossible to make a relative link without being in the directory
> so that the kernel sees both ends connected. You cannot make an absolute link
> since this is in the build root. So, I have updated the spec file with only the
> libdir fix.  

AFAIK there's nothing to prevent it. You will just get a dangling-symlink warning from rpmlint if the file you link to is not in the same rpm package.
Comment 14 Steve Grubb 2009-06-11 17:37:18 EDT
I must have had a typo when I tried it. It works. New spec file and srpm uploaded.
Comment 15 Tomas Mraz 2009-06-11 18:35:08 EDT
OK
Comment 16 Steve Grubb 2009-06-11 22:04:40 EDT
New Package CVS Request
=======================
Package Name: libcap-ng
Short Description: An alternative posix capabilities library
Owners: sgrubb
Branches: F-11 F10
InitialCC:
Comment 17 Kevin Fenzi 2009-06-12 00:32:25 EDT
cvs done.
Comment 18 Steve Grubb 2009-06-12 13:24:37 EDT
The package has been built in devel. I will build into F-11 and F-10 in the next day or two. Closing. Thanks for the review and feedback.

Note You need to log in before you can comment on or make changes to this bug.