Bug 543685
| Summary: | Package review: libnes - Driver library for libibverbs | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Doug Ledford <dledford> |
| Component: | Package Review | Assignee: | Michael Schwendt <bugs.michael> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | bugs.michael, fedora-package-review, notting |
| Target Milestone: | --- | Flags: | bugs.michael:
fedora-review+
kevin: fedora-cvs+ |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-01-03 21:00:09 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Doug Ledford
2009-12-02 20:56:22 UTC
> %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). |