https://bugzilla.redhat.com/show_bug.cgi?id=1244353 --- Comment #13 from Michael Schwendt (Fedora Packager Sponsors Group) <bugs.micheal@xxxxxxx> --- > 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 _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review