Spec URL: http://steved.fedorapeople.org/libnfsidmap/libnfsidmap.spec SRPM URL: http://steved.fedorapeople.org/libnfsidmap/libnfsidmap-0.23-1.fc14.src.rpm Description: This library used by the rpc.idmapd daemon, which is part of nfs-utils, to convert NFSv4 uid and gid strings into actual UIDs and GIDs.
rpmlint says: [steve@dolmen ~]$ rpmlint ./libnfsidmap-0.23-1.fc14.src.rpm libnfsidmap.src:10: W: mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 10) 1 packages and 0 specfiles checked; 0 errors, 1 warnings.
MUST items: Package name: ok Spec file name: ok Package Guidelines: - Spec is readable - Arch support (>1 arch) - Meets FHS - Change log format is correct - Tags ok - Requires/deps ok - Build requires ok - Summary & Description ok - Docs ok - Devel pkg content ok - post/postun ok - Uses mix of ${RPM_BUILD_ROOT} and %{buildroot} * Should use one of the other style consistently as per: https://fedoraproject.org/wiki/Packaging/Guidelines "Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and $RPM_OPT_FLAGS" - Package appears to use gettext, but there is no find_lang macro call https://fedoraproject.org/wiki/Packaging/Guidelines "Handling Locale Files" - Is is possible to use parallel make? https://fedoraproject.org/wiki/Packaging/Guidelines "Parallel make" License: ok Spec file in english: ok Spec file legible: ok Spec file successfully compiles Locale handling: see comment above System lib check: ok Relocation: N/A Owns all directories: ok Lists files only once in %files: ok Consistent use of macros: see above comment on buildroot Must contain code or permissible content: ok %doc doesn't affect runtime: ok Header files must be in -devel: ok .so in devel: ok Versioned dep for -devel: ok Must not contain .la archives: ok Must not own files/dirs owned by other packages: ok All filenames must be UTF-8: ok Thats all the must items, should items coming up shortly.
SHOULD items: COPYING file from source package should be installed under %doc Summary and description should contain translations if possible (I'm guessing that it isn't in this case, and its not really a big issue) Package builds correctly I've tested it on x86_64, I don't have any other arches to test on. Package is a library and there is no easy way to test its function without a package that depends upon it. Scriptlets are not used (so no sanity check required) Subpackages/-devel are covered under MUST and are ok No file deps, so ok on that score Includes man pages from upstream So thats all the should items.
The updated spec and srpm: http://steved.fedorapeople.org/libnfsidmap/libnfsidmap.spec http://steved.fedorapeople.org/libnfsidmap/libnfsidmap-0.23-2.fc14.src.rpm
Updated checks on comment #4 version: Should use one of ${RPM_BUILD_ROOT} or %{buildroot}: ok Local files: ok (not required) Parallel make: ok (now added) Doc files: Still doesn't appear to be including the COPYING file for some reason
Latest uploaded version now has docs correct too, so I think this is ready now.
New Package SCM Request ======================= Package Name: libnfsidmap Short Description: Library that handles mapping between names and ids for NFSv4 Owners: steved Branches: rawhide InitialCC:
"rawhide" is not a valid branch name; I've ignored it. Git done (by process-git-requests).
Provided the speed this review was rushed through, I can't deny having uneasy feeling about this review (Pingpong match?). Package is not OK: - ChangeLog date is wrong: .. * Fri Dec 3 2006 ... - Superfluous BR's: .. BR: autoconf, automake - Package supplies *.pc's => Package must own %{_libdir}/pkgconfig (recent FPG change) - Hard-coded /etc at several places. Should be %{_sysconfdir}
I agree with the first two items (and the final item) in comment #9, however, the Packaging Guidelines say: The placement of pkgconfig(.pc) files depends on their usecase. Since they are almost always used for development purposes, they should be placed in a -devel package. A reasonable exception is when the main package itself is a development tool not installed in a user runtime, e.g. gcc or gdb. about .pc files, and the Package Review Guidelines say: SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb. So while the requirement mentioned in comment #9 is perfectly reasonable, it doesn't appear to be documented at all, so perhaps the docs need updating?
(In reply to comment #10) > about .pc files, and the Package Review Guidelines say: > > SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and > this is usually for development purposes, so should be placed in a -devel pkg. > A reasonable exception is that the main pkg itself is a devel tool not > installed in a user runtime, e.g. gcc or gdb. That's not my point. My point is FPC discussed whether packages shipping a %{_libdir}/pkgconfig/*.pc should own the %{_libdir}/pkgconfig directory. Unfortunately I can't find a trace of this discussion, ATM So, I withdraw my comment - Feel free to ship this package with its broken deps.
(In reply to comment #11) > (In reply to comment #10) > > > about .pc files, and the Package Review Guidelines say: > > > > SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and > > this is usually for development purposes, so should be placed in a -devel pkg. > > A reasonable exception is that the main pkg itself is a devel tool not > > installed in a user runtime, e.g. gcc or gdb. > > That's not my point. My point is FPC discussed whether packages shipping a > %{_libdir}/pkgconfig/*.pc should own the %{_libdir}/pkgconfig directory. I don't understand this comment.... Who should own the "the %{_libdir}/pkgconfig directory"?
(In reply to comment #11) > (In reply to comment #10) > > > about .pc files, and the Package Review Guidelines say: > > > > SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and > > this is usually for development purposes, so should be placed in a -devel pkg. > > A reasonable exception is that the main pkg itself is a devel tool not > > installed in a user runtime, e.g. gcc or gdb. > > That's not my point. My point is FPC discussed whether packages shipping a > %{_libdir}/pkgconfig/*.pc should own the %{_libdir}/pkgconfig directory. > > Unfortunately I can't find a trace of this discussion, ATM Doesn't this happen implicitly? The pkgconfig auto-provs/reqs generate a provide for the shipped .pc file(s) and a require for /usr/bin/pkg-config; this comes from the pkgconfig package, which owns the %{_libdir}/pkgconfig directory.
(In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #10) > > > > > about .pc files, and the Package Review Guidelines say: > > > > > > SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and > > > this is usually for development purposes, so should be placed in a -devel pkg. > > > A reasonable exception is that the main pkg itself is a devel tool not > > > installed in a user runtime, e.g. gcc or gdb. > > > > That's not my point. My point is FPC discussed whether packages shipping a > > %{_libdir}/pkgconfig/*.pc should own the %{_libdir}/pkgconfig directory. > > > > Unfortunately I can't find a trace of this discussion, ATM > > Doesn't this happen implicitly? No. > The pkgconfig auto-provs/reqs generate a provide for the shipped .pc file(s) > and a require for /usr/bin/pkg-config; This is a bug - A package which provides a *.pc does _not_ necessarily have to require /usr/bin/pkg-config but only has to have %{_libdir}/pkgconfig owned. > this comes from the pkgconfig package, > which owns the %{_libdir}/pkgconfig directory. It's the old "plugins" vs. "dependency" issue. A package which provides an "add-on" to suport a tool, doesn't not mean this package has to depend on this tool. Wrt. libraries: Libraries are well usable without pkg-config.
This package was approved and imported in repositories and it was later retired, but this review ticket was never closed. I'm closing it now.