what's that? the for dependencies pulled "liblz4.so" hardly belongs into lz4-devel [root@flow:~]$ rpm -q --filesbypkg lz4-devel lz4-devel /usr/include/lz4.h lz4-devel /usr/include/lz4hc.h lz4-devel /usr/lib/liblz4.a lz4-devel /usr/lib/liblz4.so lz4-devel /usr/lib/liblz4.so.1 lz4-devel /usr/lib/liblz4.so.1.0.0 lz4-devel /usr/share/doc/lz4-devel lz4-devel /usr/share/doc/lz4-devel/LICENSE lz4-devel /usr/share/doc/lz4-devel/NEWS [root@flow:~]$ rpm -q --filesbypkg lz4 lz4 /usr/bin/lz4 lz4 /usr/bin/lz4c lz4 /usr/bin/lz4cat lz4 /usr/share/doc/lz4 lz4 /usr/share/doc/lz4/COPYING lz4 /usr/share/doc/lz4/NEWS lz4 /usr/share/man/man1/lz4.1.gz
Hello Herald, Thank you for reporting this issue. (In reply to Harald Reindl from comment #0) > what's that? > the for dependencies pulled "liblz4.so" hardly belongs into lz4-devel Why? I see lot of -devel packages which install .so files.
lz4-r117-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/lz4-r117-1.fc19
lz4-r117-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/lz4-r117-1.fc20
*** Bug 1104942 has been marked as a duplicate of this bug. ***
@pjp, this is not fixed with the new update. Please do not ship static libraries since a shared library is created: https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries Only the versioned shared library should be present in the base package. Unversioned shared libraries belong in -devel: https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages
lz4-r117-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/lz4-r117-2.fc20
lz4-r117-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/lz4-r117-2.fc19
@pjp, this is not fixed with the new update. Only the versioned shared library should be present in the base package. Unversioned shared libraries belong in -devel: https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages If you need help understanding this just ask.
Hello Michael, (In reply to Michael Cronenworth from comment #8) > If you need help understanding this just ask. /usr/lib/liblz4.so -> liblz4.so.1.0.0 /usr/lib/liblz4.so.1 -> liblz4.so.1.0.0 /usr/lib/liblz4.so.1.0.0 There is only one versioned library file 'liblz4.so.1.0.0', while other two are symbolic links to this file. IIUC, the guidelines say that unversioned files, ie. liblz4.so it this case, needs to go into -devel package, but since it is a symbolic link, it is included in the base package.
that symbolic links are pretty a common case for *any* library package simply because you link against libgmime-2.6 and not gmime 2.6.20 because otherwise any minor update would need a rebuild of all packages using the library the shared libraries never belong to the devel package - no idea what is that complicated to understand - the devel package contains files which are only needed to compile and link other software against your package and whenever you can't uninstall a devel-package on a customer machine or it is pulled as dependecy for non-developers it's a package bug [harry@srv-rhsoft:~]$ rpm -q --filesbypkg libzdb libzdb /usr/lib64/libzdb.so.11 libzdb /usr/lib64/libzdb.so.11.0.0 [harry@srv-rhsoft:~]$ rpm -q --filesbypkg gmime gmime /usr/lib64/libgmime-2.6.so.0 gmime /usr/lib64/libgmime-2.6.so.0.620.0
Hello Herald, (In reply to Harald Reindl from comment #10) > the shared libraries never belong to the devel package - no idea what is > that complicated to understand - the devel package contains files which are > only needed to compile and link other software against your package and > whenever you can't uninstall a devel-package on a customer machine or it is > pulled as dependecy for non-developers it's a package bug And the bug is fixed in the latest update above, right?
(In reply to pjp from comment #9) > /usr/lib/liblz4.so -> liblz4.so.1.0.0 Symbolic link or not, this file belongs in the -devel package.
@Michael Cronenworth: i personally don't care what belongs where, squashfs-tools now pulls lz4-devel which is wrong look at the initial bugreport - the lz4 package is not vital because itself depends on lz4-devel which must not happen, otherwise it makes no sense to clutter the rpmdb with two packages - period Jun 05 14:01:25 Installed: libidn2-0.8-5.fc20.x86_64 Jun 05 14:01:25 Installed: lz4-r116-1.fc20.x86_64 Jun 05 14:01:25 Installed: lz4-devel-r116-1.fc20.x86_64 Jun 05 14:01:26 Updated: squashfs-tools-4.3-4.fc20.x86_64
Package lz4-r117-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing lz4-r117-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7148/lz4-r117-2.fc20 then log in and leave karma (feedback).
lz4-r117-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/lz4-r117-3.fc20
lz4-r117-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/lz4-r117-3.fc19
Seems like there are a few issues here. It would probably be preferable to split the package up similar to how the xz tools are split. []$ rpm -qa | grep xz | sort | xargs rpm -qi | grep -e Name -e Group -e Summary Name : xz Relocations: (not relocatable) Group : Applications/File Source RPM: Summary : LZMA compression utilities Name : xz-debuginfo Relocations: (not relocatable) Group : Development/Debug Source RPM: Summary : Debug information for package xz Name : xz-devel Relocations: (not relocatable) Group : Development/Libraries Source RPM: Summary : Devel libraries & headers for liblzma Name : xz-libs Relocations: (not relocatable) Group : System Environment/Libraries Source RPM: Summary : Libraries for decoding LZMA compression With the caveat that the .a file should be in a lz4-static subpackage. Additionally, this is showing up in /usr/lib/ even on x86_64 systems. It seems like these should be in %{_libdir} instead of %{_prefix}/lib
@pjp, -%{_usr}/lib/liblz4.so.1* -%{_usr}/lib/liblz4.so +%{_libdir}/liblz4.so.1* +%{_libdir}/liblz4.so http://fedoraproject.org/wiki/Packaging:Guidelines#Macros
lz4-r117-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
lz4-r117-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Japheth Cleaver from comment #17) > With the caveat that the .a file should be in a lz4-static subpackage. Static(.a) library is not installed in lz4 package, as it is discouraged by the packaging guidelines. > Additionally, this is showing up in /usr/lib/ even on x86_64 systems. It > seems like these should be in %{_libdir} instead of %{_prefix}/lib That is a known issue, upstream Makefile installs files under /usr/lib. I've informed the upstream developer about it to.
(In reply to Michael Cronenworth from comment #18) > -%{_usr}/lib/liblz4.so.1* > -%{_usr}/lib/liblz4.so > +%{_libdir}/liblz4.so.1* > +%{_libdir}/liblz4.so Upstream Makefile installs files under /usr/lib, so the %{_libdir} does not work on x86_64 machines. I've informed the upstream developer about it. Hopefully we'll see ./configure or such script in future releases.
(In reply to pjp from comment #22) > Upstream Makefile installs files under /usr/lib, so the %{_libdir} does > not work on x86_64 machines. I've informed the upstream developer about it. > Hopefully we'll see ./configure or such script in future releases. The issue violates Fedora packaging guidelines and it is a trivial issue so it needs to be fixed sooner rather then later. You could either patch the Makefile (and submit upstream) or move the files in the spec.