Bug#456335: gtk+2.0: pkg-config files should use private depends on libraries

[Josselin Mouette]

Hi,

Le vendredi 14 décembre 2007 à 18:51 +0100, Bas Wijnen a écrit :
> For the usual case, where the library uses the other library internally,
> the relation should be written as "Requires.private:".

We have already moved a lot of these dependencies to Requires.private,
but some are more questionable. Those removals should be done very
carefully, especially because C++ packages will FTBFS if they don’t
explicitly link to a library they require.


* gdk-pixbuf-2.0.pc

This is the only one requiring gobject-2.0 and gmodule-no-export-2.0.
Which is highly questionable, because all libraries should require
gobject, and gtk should require gmodule. I suspect other libraries
require gdk-pixbuf only to get these dependencies.

* gdk-x11-2.0.pc

Here, the dependency on gdk-pixbuf-2.0 should probably be moved to
Requires.privates, but replacing it with gobject-2.0.

Only remain pango and pangocairo. The GdkPango primitives heavily rely
on pango types and functions, and any code using them is bound to use
pango functions as well.

However it can be argued that in these cases the application should
already depend on pangocairo by itself, so it looks fine to remove them.

* gtk+-x11-2.0.pc

I think it is hopeless to remove gdk-x11-2.0. GTK+ relies so heavily on
GDK that most applications using both are probably requiring only GTK+.
Removing it will only break many applications.

Atk only looks accessible by functions returning Atk types, so I guess
it could be removed.

I don't understand why cairo is here. It should be in gdk-x11-2.0,
because this is where the cairo interface lies.

* gtk+-unix-print-2.0.pc

This is merely a wrapper that always bring gtk+-x11-2.0. Anything else
should be removed.

* gdk-pixbuf-xlib-2.0.pc

gobject and gdk-pixbuf-2.0 should be kept. I don’t think there’s any
point for gmodule, even in Requires.privates.

* gtk+-directfb-2.0.pc

Same as gtk+-x11.

* gdk-directfb-2.0.pc

This one is a giant mess, and the reason is the rpath. Everything fails
if the rpath isn’t propagated to *all* binaries linking to the library,
even indirectly. The real solution is, before any other fix, to get rid
of this rpath and give the directfb version of cairo a different soname.


Because all these dependencies are created by the configure script, it
is a lot of work to remove them properly, so don’t expect this to be
done in a snap. I also think we should prepare a package in experimental
and ask for a full archive rebuild with it.

-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20071217/f6f256c8/attachment.pgp