[Fedora-packaging] Re: Automatic detection of Requires and versions

[Axel Thimm]

On Mon, Jan 07, 2008 at 04:20:54PM +0100, Ralf Corsepius wrote:
>  
>  On Mon, 2008-01-07 at 16:15 +0100, Patrice Dumas wrote:
>  > On Mon, Jan 07, 2008 at 10:40:05AM -0200, Eduardo M KALINOWSKI wrote:
>  > > Hi,
>  > > 
>  > >     I'm attempting to package a program I wrote, that uses the GTK+
>  > > libraries. It uses features first found in the 2.10.X series, so I
>  > > include
>  > > 
>  > > BuildRequires: gtk2-devel >= 2.10.0
>  > > 
>  > > (and similar lines for glib and other required libraries). All this is
>  > > OK. The problem is regarding the Requires for the generated .rpm. I
>  > > could use
>  > > 
>  > > Requires: gtk2 >= 2.10.0
>  > > 
>  > > but apparently this is bad style and bad for maintenance, because
>  > > dependencies are found automatically on build time. However, without
>  > > manually adding the requires, the generated .rpm contains (with regard
>  > > to GTK+) this:
>  > > 
>  > > libgtk-x11-2.0.so.0
>  > > 
>  > > that is, no mention of the version, and I expect that even a GTK+ 2.8
>  > > package (old as that may be) should provide that file with that name.
>  > > 
>  > >     What is the best way to handle that? Include the Require manually?
>  > > Leave this as-is?
>  > 
>  > I'd say the reverse than Rex, include the Require manually. But I may
>  > well be wrong.
>  
>  Well, you are. If an upstream has its package properly designed (Esp.
>  uses SONAMEs properly), then there should not be any need to let a
>  run-time/application-package explicitly require a package by name. 
That's a big if actually. But I would reason differently - if the
package *build* ensured that gtk2-devel was larger than 2.10.0 then
gtk2 will also be larger than that when pulled from the same repo. So
in the (usual) case of using a Fedora X package within Fedora X one
doesn't have to add versioned Requires:.

In the rare case that one would want to use the package in a different
environment then things change - for example it has happened a couple
of times in the past that using a package built on the *updated*
gtk2/glib2 will require symbols not found in the non-updated *release*
version and will break the app. It has happened with synaptic a couple
of times, e.g. a user installs from DVD then wants to use apt/synaptic
from updates-released to update his system and this synaptic bails out
as it is not compatible to the old libs from the release (I think it
was glib2 that had some more symbols used than the release had)

In order to avoid this catch22 depsolver updates should in theory be
built against the released non-updated bits only, but this is probably
not really worth the trouble - I once maintained non-updated build
chroots just for that reason until the maintenance was too much to
handle (and all depsolvers eventually made it into Fedora anyway, so I
hadn't had to deal with the problem anymore ;)
-- 
Axel.Thimm at ATrpms.net