[Bug 1244353] Review Request: ossim - Open Source Software Image Map

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1244353



--- Comment #13 from Michael Schwendt (Fedora Packager Sponsors Group) <bugs.micheal at gmx.net> ---
> 3) ossim-devel.x86_64: E: library-without-ldconfig-postin /usr/lib64/libossim.so.1.8.18
> 
> I also have no idea why the error occurs,

It's an error, because the files are misplaced. Let's take a look:

| %files
| %{_libdir}/libossim.so.*
| 
| %files devel
| %{_includedir}/ossim*
| %{_libdir}/*.so*

First of all, the wildcards "libossim.so.*" and "*.so*" overlap. The latter
also includes the former, i.e. "*.so*" also matches files matched by "*.so.*"
and hence "libossim.so.*", too.

Since you duplicate shared libs in two packages, you probably don't see any
symptoms at runtime, but have you examined the package dependencies yet? Run
"rpm -qp --whatrequires …" and "rpm -qp --whatprovides …" on the built binary
packages. That's important for understanding RPM package dependencies.

Secondly, the important thing about placement of .so files is to decide when
they are needed. At runtime? Or at buildtime only? Or at runtime _and_ at
buildtime?

libossim.so.1.8.18 is a runtime library to be put into the base package. Same
for libossim.so.1 and further versions that result in _automatic_ dependencies
in your packages.

On the contrary, an unversioned symlink libossim.so is what makes linking at
buildtime work. Without libossim.so the compiler would not find the library
when given the -lossim linker option.

[Finally, the third case is rare. A program doing a dlopen() call (or something
similar) to open an unversioned shared library at runtime. Such a case can be
nasty, because there are no automatic RPM dependencies you can rely on, and if
the unversioned .so file is shipped in a -devel package, this can get ugly if
the library is needed at runtime always.]


| %post -n ossim -p /sbin/ldconfig
| 
| %postun -n ossim -p /sbin/ldconfig

Now back to the error. You execute ldconfig for the base "ossim" package only,
but rpmlint complains about the -devel subpackage (!) where you include runtime
libraries, too. The fix would be to not include any runtime libs in the -devel
package, and then you don't need to run ldconfig for it either (which would be
the normal case, btw).

The explicit "-n ossim" is not needed, btw. The base package name is the
default for scriptlet sections lacking an -n option.

[...]

The package needs quite a bit of more work. These are just some drive-by
comments.


Try pointing the fedora-review tool at this ticket:

  fedora-review -b 1244353

It will download the latest spec file and src.rpm from the "Spec URL:" and
"SRPM URL:" lines you include in your comments and perform many helpful checks.


There is the helpful %{_fixperms} macro for correcting permissions with the
source tree:

  $ rpm -E %_fixperms
  /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w


> %package 	apps
> Summary:        %{sname} applications
> Group:          System Environment/Libraries
> Requires:       %{name}%{?_isa} = %{version}-%{release}

An unusual Group tag for files in %_bindir. The tag is optional nowadays, so
you may want to remove it everywhere from the spec file.


> %package	    doc
> Summary:        Documentation for %{sname}
> Group:          Documentation
> Requires:       %{name}%{?_isa} = %{version}-%{release}

A -doc subpackage for two files? You cannot be happy with that either:

 | %files doc
 | %doc ossim/README.txt
 |
 | %license ossim/LICENSE.txt

And clearly such a -doc package does not strictly need to depend on the base
package and all its dependencies. That's a lot of overhead for anyone, who
would only like to peruse the documentation (e.g. when evaluating/considering
whether to use the software).

Btw, there are specific guidelines on where to include the license text:
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text


> %package	    data
> Summary:        Additional data files for %{sname}
> Group:          Documentation
> Requires:       %{name}%{?_isa} = %{version}-%{release}

A strange Group tag here, too. And files in /usr/share are supposed to be
arch-independent, so the -data subpackage should be made "BuildArch: noarch".

The summary says "additional data files". Where are the other data files? There
are none. These are the only packaged data files. So, %summary and %description
should tell what these are for and why/when you may want to install this
optional package. A hint about the included profile.d files and what they do
would be added value, too.


The spec files included in the source tarball are very different.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component