Bug 818910 - ipmiutil : does not adhere to Static Library Packaging Guidelines
ipmiutil : does not adhere to Static Library Packaging Guidelines
Product: Fedora
Classification: Fedora
Component: ipmiutil (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Andy Cress
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2012-05-04 06:44 EDT by Michael Schwendt
Modified: 2014-12-25 02:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-12-25 02:11:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
ipmiutil.spec with changes (13.77 KB, text/plain)
2012-05-04 11:08 EDT, Andy Cress
no flags Details
ipmiutil.spec with rpmlint fixes (13.22 KB, text/plain)
2012-05-04 12:48 EDT, Andy Cress
no flags Details
ipmiutil.spec with style changes from comment #8 (13.30 KB, text/plain)
2012-05-25 12:51 EDT, Andy Cress
no flags Details

  None (edit)
Description Michael Schwendt 2012-05-04 06:44:52 EDT

Build: ipmiutil-2.8.3-1.fc18.src.rpm

    contains only static libraries,
    but no virtual -static package is provided
Comment 1 Michael Schwendt 2012-05-04 06:50:57 EDT
While at it, could you also revisit the -devel package header location? /usr/share instead of /usr/include is highly questionable, not only because the sample doesn't adjust the search path for headers either:

$ rpmls -p ipmiutil-devel-2.8.3-1.fc18.x86_64.rpm 
-rw-r--r--  /usr/lib64/libipmiutil.a
-rw-r--r--  /usr/share/ipmiutil/Makefile
-rw-r--r--  /usr/share/ipmiutil/ipmi_sample.c
-rw-r--r--  /usr/share/ipmiutil/ipmicmd.h
Comment 2 Andy Cress 2012-05-04 11:07:31 EDT
OK, proposed changes made to ipmiutil.spec (attached).
This will go into the upstream and a patch to fc18 will be added, if this is ok.
Comment 3 Andy Cress 2012-05-04 11:08:26 EDT
Created attachment 582143 [details]
ipmiutil.spec with changes
Comment 4 Michael Schwendt 2012-05-04 11:41:37 EDT
Hmmm, that spec file wouldn't pass the review process. Has the packaging changed so much since its initial version?

This bug report has been opened automatically by a script. I didn't mean to re-review your package, but there are several issues with it now that I've had a look at the spec file. Please run rpmlint on the src.rpm and the built rpms. It finds a couple of bugs as a start. Try to review your package based on this page:


> %post devel
> /sbin/ldconfig

There doesn't make sense, because there are no shared libs within the package(s), and even if there were, typically one doesn't run ldconfig in the -devel package but in the base library package.
Comment 5 Andy Cress 2012-05-04 12:48:00 EDT
Yes, it has undergone some changes, particularly around systemd support.
Attached is an updated ipmiutil.spec which looks rpmlint clean.
Comment 6 Andy Cress 2012-05-04 12:48:49 EDT
Created attachment 582159 [details]
ipmiutil.spec with rpmlint fixes
Comment 7 Andy Cress 2012-05-14 11:23:41 EDT
Does this attachment 582159 [details] look ok?
Comment 8 Michael Schwendt 2012-05-24 08:12:20 EDT
Yeah, it would fix the static lib package bug. :)

With regard to other albeit unrelated issues:

> BuildRequires: openssl-devel gcc gcc-c++ libtool


Not a MUST item, though. However, omitting "gcc gcc-c++" in BuildRequires make it easier to build packages in an altered build environment with replaced compilers.

> %define systemd_fls %{_datadir}/%{name}
> %define init_dir  %{_initrddir}


> %package devel
> [...]
> Requires: ipmiutil


Since it's a -static-only -devel package, I guess it does not need the base package to be usable when compiling something. It just shares a directory with the base package to store the example source in. You could include the directory entry in both packages and drop the explicit dependency (if directory ownership is the only reason for it) and add a comment to the spec file:


> make

Comment 9 Andy Cress 2012-05-25 12:49:45 EDT
Implemented the other changes, but I differ on the 'BuildRequires: gcc gcc++'.
I have seen more occurrences of VM auto-build systems that don't auto-install gcc and I have built cleanly without any issues in several custom compiler build environments.
Comment 10 Andy Cress 2012-05-25 12:51:34 EDT
Created attachment 586901 [details]
ipmiutil.spec with style changes from comment #8
Comment 11 Andy Cress 2012-05-25 12:52:58 EDT
I'll submit the new files to Fedora rawhide soon as a fix for this bug.
Comment 12 Fedora Update System 2012-06-12 13:56:34 EDT
ipmiutil-2.8.4-1.fc16 has been submitted as an update for Fedora 16.
Comment 13 Fedora Update System 2012-06-14 20:21:34 EDT
Package ipmiutil-2.8.4-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ipmiutil-2.8.4-1.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 14 Fedora Update System 2012-06-25 20:34:18 EDT
ipmiutil-2.8.4-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Fedora Update System 2012-08-21 12:16:13 EDT
ipmiutil-2.8.5-2.fc18 has been submitted as an update for Fedora 18.
Comment 16 Fedora Update System 2012-09-17 17:57:32 EDT
ipmiutil-2.8.5-2.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 17 Michael Schwendt 2014-10-16 12:25:20 EDT
Reopened by: fedora-report-static-batch.py

Build: ipmiutil-2.9.4-1.fc22.src.rpm

    /usr/lib/libipmiutil.so  <=>  /usr/lib/libipmiutil.a
Comment 18 Andy Cress 2014-10-16 13:57:51 EDT
OK, what is the non-compliance with this?  It doesn't say.
Comment 19 Michael Schwendt 2014-10-16 15:13:47 EDT
[yep, I need to update the hardcoded texts in the script]

It's this:


1. Static libraries and shared libraries. In this case, the static libraries must be placed in a *-static subpackage. Separating the static libraries from the other development files in *-devel allow us to track this usage by checking which packages BuildRequire the *-static package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries.
Comment 20 Michael Schwendt 2014-10-16 15:45:21 EDT
Oh, ipmiutil is mispackaged, btw. It includes the shared runtime library in the -devel subpackage:

Comment 21 Andy Cress 2014-10-23 09:59:06 EDT
Yes, I have added the shared library to the devel package, so now that this is no longer a static-only package, I need to move the static library into a '-static' package.
Comment 22 Andy Cress 2014-11-07 17:49:50 EST
The upstream ipmiutil-2.9.5 now includes a compliant spec file separating out the static lib into a -static package.
I'll apply that to the fedora rawhide shortly.  

BTW, I had a request to apply the ipmiutil package to epel7, but I don't seem to have access to do that.  How do I get access to epel7?
Comment 24 Michael Schwendt 2014-12-25 02:11:13 EST
Closed by: fedora-report-static-batch.py

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