handling of symlinks to symlinks in spec file
domen.vrankar at gmail.com
Sun Apr 17 19:27:12 UTC 2016
Sorry for the delayed reply.
You misunderstood me regarding "autoreq: no". For me that does solve
Hm did not notice that files were missing but your analysis helped me
to figure out what was wrong - see the steps to reproduce below.
Meanwhile I've found out what the problem was:
When you've mentioned the missing execute bit it occurred to me that I
was too focused on why the second symlink was causing the issue that I
completely overlooked that...
Adding the owner execute bit to the library solves the problem. It
would seem that during auto dependencies resolution rpmbuild figures
out that the file is a library but once it is created and missing
execute bit it fails during installation - would be nice if that was
checked for during packaging resulting in an error (preferred) or no
error at all during installation (specially no different rpm command
response if there is only one symlink or a chain of two).
What is odd is that this only happens if you have a chain of two
symlinks - with one symlink rpm installs without error.
This also doesn't happen if symlinks are linked to a plain text file.
How to reproduce:
1. Remove execute bit from a library (in this case liblibrary.so.5.6.7
- please ignore the names as they don't change anything regarding the
2. Create a symlink pointing to that library (ln -s
3. Create a symlink pointing to the previously created symlink (ln -s
4. Create a package
5. Install the package (error should occur)
I'm missing permissions to report this bug here
(http://www.rpm.org/newticket) so I hope that this is enough.
2016-04-14 11:29 GMT+02:00 Lubos Kardos <lkardos at redhat.com>:
> You sent me archive containing only spec file and generated rpm so I can't try
> to rebuilt package:
> The generated rpm contains one shared object /usr/lib/liblibrary.so.5.6.7 with
> soname libtest_lib.so and two symlinks. I don't understand where does the
> require libtest_lib.so()(64bit) come from. liblibrary.so.5.6.7 doesn't require
> itself. But I noticed that the file /usr/lib/liblibrary.so.5.6.7 doesn't have
> set executable bit so it is ignored by automatic provides generation and that
> is why no libtest_lib.so()(64bit) provides is created.
> There is a lot of other problems with this rpm. I don't understand why you
> need soname different from the name of the file. The soname should contain
> major version number. Link /usr/lib/liblibrary.so.0 -> liblibrary.so.5.6.7
> doesn't seem to be correct and so on.
> Why "autoreq: no" doesn't work for you I don't know as I wrote you didn't send
> me everything needed to test it.
> ----- Original Message -----
>> From: "Domen Vrankar" <domen.vrankar at gmail.com>
>> To: "General discussion about the RPM package manager" <rpm-list at lists.rpm.org>
>> Sent: Tuesday, April 12, 2016 9:08:40 AM
>> Subject: Re: handling of symlinks to symlinks in spec file
>> 2016-04-12 8:21 GMT+02:00 Lubos Kardos <lkardos at redhat.com>:
>> > Sorry, I wanted to write, I can't reproduce the problem.
>> > Lubos
>> > ----- Original Message -----
>> >> From: "Lubos Kardos" <lkardos at redhat.com>
>> >> To: "General discussion about the RPM package manager"
>> >> <rpm-list at lists.rpm.org>
>> >> Sent: Tuesday, April 12, 2016 8:20:02 AM
>> >> Subject: Re: handling of symlinks to symlinks in spec file
>> >> Hi,
>> >> I can reproduce this problem, can you provide a minimal reproducer.
>> >> Ideally
>> >> the
>> >> srpm package from which the problematic rpm can be built.
>> >> Lubos
>> Thanks for looking into this.
>> Attached is a minimal example.
>> Extract it in /tmp, move into RPM directory and execute:
>> /usr/bin/rpmbuild -bb --define "_topdir /tmp/RPM" --buildroot
>> "/tmp/RPM/project1-1.2.1-Linux" --target "x86_64"
>> I've left an already generated rpm package in RPM dir.
>> Spec file is a cleaned up version of what CPack/RPM produces.
>> Rpm-list mailing list
>> Rpm-list at lists.rpm.org
> Rpm-list mailing list
> Rpm-list at lists.rpm.org
More information about the Rpm-list