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
Attachment:
pgp9zhvEyuGdb.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
