[Fedora-packaging] Missing 'Provides:' from rpmdeps, apparently?

Ralf Corsepius rc040203 at freenet.de
Tue Dec 18 09:15:07 UTC 2012


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



More information about the packaging mailing list