libnes is a simple package that provides a low level hardware driver for the libibverbs package. The current package requires libibverbs-1.1.3 or later to compile, and prebuilt versions as well as the spec file and srpm can be found on my person web page at: http://xsintricity.com/dledford/Package_Review/ rpmlint shows the following: [dledford@firewall rpmbuild]$ rpmlint SRPMS/libnes-0.9.0-1.fc12.src.rpm RPMS/x86_64/libnes-* libnes.src:12: W: unversioned-explicit-provides libibverbs-driver libnes.x86_64: W: non-conffile-in-etc /etc/libibverbs.d/nes.driver libnes-static.x86_64: W: no-documentation 4 packages and 0 specfiles checked; 0 errors, 3 warnings. The first one is correct as it's a psuedo provides that only exists for the purpose of causing a yum install of libibverbs to pull in all the hardware drivers that make libibverbs operate. The second is a side effect of the libibverbs package. It requires the file in this location, but the file is not user changable and should not therefore be labeled as a conf file. The final one is because the -static package only has one file, the static library. All the docs are in the base package.
> %makeinstall Avoid this macro unless normal "make DESTDIR=${RPM_BUILD_ROOT} install" (with an optional INSTALL="install -p" doesn't work. Add a comment if you really need this macro. The way %makeinstall overrides variables to insert the buildroot path bears risks and has lead to problems before. > %{_sysconfdir}/libibverbs.d/*.driver "repoquery --whatprovides /etc/libibverbs.d" on Fedora 12 returns nothing, which means it's an unowned directory. Most likely in package "libibverbs". > %package static > Summary: Static version of the libnes driver > Group: System Environment/Libraries Rather "Development/Libraries". > Provides: %{name}-devel = %{version}-%{release} ... > %files static > %defattr(-,root,root,-) > %{_libdir}/*.a A static library without any headers? Isn't this package missing a dependency on some -devel package that would define the API for this lib? Same question applies to the virtual -devel package.
(In reply to comment #1) > > %makeinstall > > Avoid this macro unless normal "make DESTDIR=${RPM_BUILD_ROOT} install" (with > an optional INSTALL="install -p" doesn't work. Add a comment if you really need > this macro. The way %makeinstall overrides variables to insert the buildroot > path bears risks and has lead to problems before. Fixed. > > %{_sysconfdir}/libibverbs.d/*.driver > > "repoquery --whatprovides /etc/libibverbs.d" on Fedora 12 returns nothing, > which means it's an unowned directory. Most likely in package "libibverbs". New version of libibverbs being built that now owns this directory. > > %package static > > Summary: Static version of the libnes driver > > Group: System Environment/Libraries > > Rather "Development/Libraries". Fixed. > > Provides: %{name}-devel = %{version}-%{release} > ... > > %files static > > %defattr(-,root,root,-) > > %{_libdir}/*.a > > A static library without any headers? Isn't this package missing a dependency > on some -devel package that would define the API for this lib? Same question > applies to the virtual -devel package. Yes and no. Even if a user application directly links this file into their code, they wouldn't ever be calling it and wouldn't need any API information. This static library only serves a purpose when the user is also statically linking libibverbs into their application (in which case presumably they have the libibverbs-devel package already installed, which is the yes part of the answer), however even then, this library is actually only linked against libibverbs while the user code is also only linked against libibverbs, and since the libibverbs static library is already compiled just as this is, there really isn't any requirement for headers to define the API during the link process. So yes in the sense that the user space code probably needs the libibverbs headers before this is useful, but no in the sense that this library itself doesn't have any requirements as it's only going to be linked against other object code.
* Similar to review bug 543689 (libipathverbs). $ sha1sum libnes-0.9.0.tar.gz 6e9374ea9ace5e052c00aa868eea6793839d1ae8 libnes-0.9.0.tar.gz * Virtual arch-specific -devel%{?_isa} Provides could be added. Same as in review bug 543689. * In this package, the -static subpkg contains the -devel Provides, whereas in libipathverbs, it's the base driver package that contains the -devel Provides. That's inconsistent. * Things mentioned in this comment could be fixed in fedora pkg cvs, so: APPROVED
> the -static subpkg contains the -devel Provides Ah, this is problem actually, because anything with "BuildRequires: libnes-devel" would implicitly get libnes-static. [ https://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libraries_2 ]
Thanks Michael. I'll fix up the last remaining items (including the provides) in CVS. Rel-eng: I would like an F-13 and devel branches please.
Please add a cvs template here (see http://fedoraproject.org/wiki/CVS_admin_requests ) and reset the fedora-cvs flag to ?
New Package CVS Request ======================= Package Name: libnes Short Description: Hardware driver for NetEffect hardware, used by libibverbs Owners: dledford Branches: F-13,devel InitialCC:
CVS done (by process-cvs-requests.py).