Missing 'Provides:' from rpmdeps, apparently?

[John Pye]

Hi all

It's been a while (a couple of years) since I packaged an RPM, and a few 
things appear to have changed. In particular one thing that has got me 
completely stuck is the automatic dependency tracking, in particular the 
'Provides' tagging doesn't seem to work as expected.

I have a package that installs a shared library in 
/usr/lib64/libfreesteam.so.1, and I want that package to automatically 
be tagged with "Provides: libfreesteam.so.1()(64bit)" however nothing I 
do seems to cause the automatic dependency tracking to create that tag.

If I install my package, and run the following, I get the expected output:

[john@fed17-64 ~]$ rpm -ql freesteam | /bin/sh -c " while read FILE; do 
/usr/lib/rpm/rpmdeps -P ${FILE}; done | /bin/sort -u "
libfreesteam.so.1()(64bit)

But for some reason, while in principle the same thing is being done 
during the package build, the resulting libfreesteam.so.1()(64bit) 
Provides tag does not get generated:

[john@fed17-64 freesteam]$ rpm -p 
/home/john/rpmbuild/RPMS/x86_64/freesteam-2.1-0.f17.x86_64.rpm -q --provides
freesteam = 2.1-0.f17
freesteam(x86-64) = 2.1-0.f17
[john@fed17-64 freesteam]$ rpm -p 
/home/john/rpmbuild/RPMS/x86_64/freesteam-devel-2.1-0.f17.x86_64.rpm -q 
--requires
freesteam = 2.1-0.f17
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
libfreesteam.so.1()(64bit)
/usr/bin/env
rpmlib(PayloadIsXz) <= 5.2-1

This of course has the result that my 'devel' package doesn't install 
because it has a dependency on libfreesteam.so.1()(64bit) that it 
doesn't know how to satisfy.

Can anyone set me straight on what is going on here?  (One thing that I 
notice is that shared libraries in Ubuntu use 644 mode, but Fedora 17 
uses 755. But I believe I've corrected for that using %defattr. Also I 
am getting automatically-generated dependencies on /bin/sh and 
/usr/bin/env that I am surprised by)

Cheers
JP

If you want to check out my code, it's here:
http://sourceforge.net/p/freesteam/code/

I use:
sudo yum install gsl-devel scons swig python-devel
scons dist
rpmbuild -ta dist/freesteam-2.1.tar.bz2

[Toshio Kuratomi]

On Tue, Dec 18, 2012 at 02:15:14PM +1100, John Pye wrote:
>  
>  Can anyone set me straight on what is going on here?  (One thing that
>  I notice is that shared libraries in Ubuntu use 644 mode, but Fedora
>  17 uses 755. But I believe I've corrected for that using %defattr.
>  
What happens if you use chmod 0755 %{buildroot}%{_libdir}/lib*so*
in %install ?  I haven't checked recently but traditionally, the provides
and requires scripts only checked shared libraries that were mode 0755.

>  Also I am getting automatically-generated dependencies on /bin/sh
One reason for this is that you have %post and %postun scripts.  Those
automaticaly use /bin/sh as the interpreter unless told otherwise.

Since you only call ldconfig there, you could do them like ths instead:
%post -p /sbin/ldoncifg

That will invoke /bin/ldconfig directly without the need of the shell.
However:

>  and
>  /usr/bin/env that I am surprised by)
>   
This likely means that you're installing a script somewhere that has
/usr/bin/env in its shebang line that rpm is finding.

-Toshio

[John Pye]

Hi Toshi, and thanks for your suggestions:

On 18/12/12 15:35, Toshio Kuratomi wrote:
>  On Tue, Dec 18, 2012 at 02:15:14PM +1100, John Pye wrote:
> > Can anyone set me straight on what is going on here?  (One thing that
> > I notice is that shared libraries in Ubuntu use 644 mode, but Fedora
> > 17 uses 755. But I believe I've corrected for that using %defattr.
> >
>  What happens if you use chmod 0755 %{buildroot}%{_libdir}/lib*so*
>  in %install ?  I haven't checked recently but traditionally, the provides
>  and requires scripts only checked shared libraries that were mode 0755. 
This was the right solution. Indeed, the 'find-provides' or 'rpmdeps' 
stuff only works if the shared library .so files are installed with the 
executable bit set. It's *not* enough to use '%defattr' in the %files 
section(s).

I couldn't find this fact mentioned ANYWHERE in the documentation, FWIW, 
and it's especially a concern/difficulty since this +x marking is 
different from the practice on Debian systems.

> > Also I am getting automatically-generated dependencies on
> /bin/sh
>  One reason for this is that you have %post and %postun scripts.  Those
>  automaticaly use /bin/sh as the interpreter unless told otherwise.
>
>  Since you only call ldconfig there, you could do them like ths instead:
>  %post -p /sbin/ldoncifg
>
>  That will invoke /bin/ldconfig directly without the need of the shell.
>  However: 
That seems to be a good idea, and replaces the 'sh' dependency with 
'/sbin/ldconfig' instead.

> > and
> > /usr/bin/env that I am surprised by)
> >
>  This likely means that you're installing a script somewhere that has
>  /usr/bin/env in its shebang line that rpm is finding. 
Actually what was happening here is that I have a 'freesteam-config' 
script that starts with "#!/usr/bin/env python". Should I ideally change 
that script to start with #!/usr/bin/python, or is the /usr/bin/env 
approach considered acceptable, and I just add "Requires: python" for 
the devel package instead?

Cheers
JP

-- 
http://jpye.dyndns.org

[Ralf Corsepius]

On 12/18/2012 06:24 AM, John Pye wrote:
>  Hi Toshi, and thanks for your suggestions:
>
>  On 18/12/12 15:35, Toshio Kuratomi wrote:
> > On Tue, Dec 18, 2012 at 02:15:14PM +1100, John Pye wrote:
> >> Can anyone set me straight on what is going on here?  (One thing that
> >> I notice is that shared libraries in Ubuntu use 644 mode, but Fedora
> >> 17 uses 755. But I believe I've corrected for that using %defattr.
> >>
> > What happens if you use chmod 0755 %{buildroot}%{_libdir}/lib*so*
> > in %install ?  I haven't checked recently but traditionally, the provides
> > and requires scripts only checked shared libraries that were mode 0755.
>
>  This was the right solution. Indeed, the 'find-provides' or 'rpmdeps'
>  stuff only works if the shared library .so files are installed with the
>  executable bit set. It's *not* enough to use '%defattr' in the %files
>  section(s).
>
>  I couldn't find this fact mentioned ANYWHERE in the documentation, 
Likely,
because people have been taking it for granted, because it's the 
default everywhere (except on Debian'sh systems) for ages ;)

>  FWIW,
>  and it's especially a concern/difficulty since this +x marking is
>  different from the practice on Debian systems. 
Right. It's a historic
convention, which AFAICT predates Linux and which 
once was technically necessary. Debian has abandoned it, RH/Fedora and 
many others distros and OSes haven't.

> >> /usr/bin/env that I am surprised by)
> >>
> > This likely means that you're installing a script somewhere that has
> > /usr/bin/env in its shebang line that rpm is finding.
>
>  Actually what was happening here is that I have a 'freesteam-config'
>  script that starts with "#!/usr/bin/env python". Should I ideally change
>  that script to start with #!/usr/bin/python, 
Yes. This is the favored approach.

>  or is the /usr/bin/env
>  approach considered acceptable, 
No.

>  and I just add "Requires: python" for
>  the devel package instead? 
No.

Ralf