Now I realized this is not about chain of two symlinks but about simlink with linker name (*.so) pointing to shared object. These simlinks with linker names are usually in -debug packages and shared objects which they point to are in main packages. The dependency in a devel package on a main package is automatically created. This require dependency is created by /usr/lib/rpm/fileattrs/libsymlink.attr file. There is no bug to fix, this is expected behavior. Rpm can't know that your package fulfill the libtest_lib.so()(64bit) dependency itself if the corresponding shared object is not executable. Contrary the most of packages don't fulfill dependencies like this by themselves because they are divided into main and devel packages. If you don't like this standard behavior, you can turn of automatic dependency generation completely or the better way is just filter out problematic requires and provides [1] and the best way is create package which doesn't have problems with this standard behavior of course. How to create such non-problematic packages for Fedora is described here [2]. Lubos [1] https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering [2] https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines ----- Original Message ----- > From: "Domen Vrankar" <domen.vrankar@xxxxxxxxx> > To: "General discussion about the RPM package manager" <rpm-list@xxxxxxxxxxxxx> > Sent: Sunday, April 17, 2016 9:27:12 PM > Subject: Re: handling of symlinks to symlinks in spec file > > Sorry for the delayed reply. > > You misunderstood me regarding "autoreq: no". For me that does solve > the problem. > 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. Now I realized this is not about chain of two symlinks but about simlink with linker name (*.so) pointing to shared object. These siml > 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 > issue) > 2. Create a symlink pointing to that library (ln -s > liblibrary.so.5.6.7 liblibrary.so.5) > 3. Create a symlink pointing to the previously created symlink (ln -s > liblibrary.so.5 liblibrary.so) > 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. > > Thanks, > Domen > > 2016-04-14 11:29 GMT+02:00 Lubos Kardos <lkardos@xxxxxxxxxx>: > > You sent me archive containing only spec file and generated rpm so I can't > > try > > to rebuilt package: > > > > RPM/SOURCES/ > > RPM/BUILD/ > > RPM/ > > RPM/SPECS/ > > RPM/RPMS/ > > RPM/BUILDROOT/ > > RPM/SPECS/project1.spec > > RPM/project1-1.2.1-Linux.rpm > > RPM/SRPMS/ > > RPM/tmp/ > > > > 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. > > > > Lubos > > > > ----- Original Message ----- > >> From: "Domen Vrankar" <domen.vrankar@xxxxxxxxx> > >> To: "General discussion about the RPM package manager" > >> <rpm-list@xxxxxxxxxxxxx> > >> 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@xxxxxxxxxx>: > >> > Sorry, I wanted to write, I can't reproduce the problem. > >> > > >> > Lubos > >> > > >> > ----- Original Message ----- > >> >> From: "Lubos Kardos" <lkardos@xxxxxxxxxx> > >> >> To: "General discussion about the RPM package manager" > >> >> <rpm-list@xxxxxxxxxxxxx> > >> >> 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" > >> "/tmp/RPM/SPECS/project1.spec" > >> > >> I've left an already generated rpm package in RPM dir. > >> > >> Spec file is a cleaned up version of what CPack/RPM produces. > >> > >> Thanks, > >> Domen > >> > >> _______________________________________________ > >> Rpm-list mailing list > >> Rpm-list@xxxxxxxxxxxxx > >> http://lists.rpm.org/mailman/listinfo/rpm-list > >> > > _______________________________________________ > > Rpm-list mailing list > > Rpm-list@xxxxxxxxxxxxx > > http://lists.rpm.org/mailman/listinfo/rpm-list > _______________________________________________ > Rpm-list mailing list > Rpm-list@xxxxxxxxxxxxx > http://lists.rpm.org/mailman/listinfo/rpm-list > _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
