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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



--- Comment #15 from Rashad M <rashad.kanavath@xxxxxx> ---
(In reply to Michael Schwendt (Fedora Packager Sponsors Group) from comment
#13)
> > 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
> 
do you have an example usage? When I googled, it was executed after setup
macro?

so should I run it on buildroot?
> 
> > %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

Can I move the readme in the base package and remove -doc package?

> 
> 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".
> 
removed all Group tag and also set BuildArch:noarch for data package

> 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.
> 

There are some csv files in ossim/share/projection
and templates of keywordlists. I will update the description.

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

I updated the spec but couldn't host the srpm for the new version.

-- 
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




[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]