Josselin Mouette wrote: > Le dimanche 09 décembre 2007 à 15:44 -0800, Steve Langasek a écrit : >>> For example, pkg-config --libs gtk+-x11-2.0 will return, among others, I don't have a problem with libglib2.0-0 in gtk+2.0.pc - it may well be correct to have that one in the pkgconfig because gtk headers define variables in terms of Glib typedefs. (I have to do the same with libqof1). The actual string is: -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 As I see it, there are a few problems here, one of which is in libglib2.0: 1. Glib: gmodule2.0 (and it's variants) shouldn't export -ldl. This is minor because it's a libc6 lib anyway so it doesn't cause an extra dependency but it will be the only "unwanted" link in the next version of libqof1 now that I've fixed the others. 2. Gtk+2.0 really shouldn't export gmodule. Even if there is a reason for lglib2.0, there is no reason for -lgmodule. It is trivial to omit this linkage from the gtk+2.0.pc file. 3. Ditto for gobject although I might be wrong on that one. 4. Gtk+2: There is no need, as I see it, for atk, m, pangocairo, pango or cairo to be Requires: in gtk+2.0.pc - these should be Requires.private: instead. This is the single largest cause of unwanted linking in GPE. Sadly, it isn't possible to get lintian to check for these inter-package problems but the basic check, IMHO, would be to check the headers of the -dev package against the headers of the package being considered for Requires: If none match, it should be Requires.private: It should be possible to automate that in perl or python - gather the declarations of your package into a hash, read in the declarations of the package being considered for Requires:. No matches -> Requires.private or omit altogether. The problem is how many packages already have this assumption built-in and will FTBFS when gtk+2.0.pc changes to drop the extra libraries. Theoretically, other packages should have done things properly and specified their -dev packages in full but I think that isn't going to be the reality. >>> -lglib-2.0 and -lm. And this is perfectly intentional. >> Just because it's intentional doesn't mean it isn't absurd and wrong. > > It may be absurd, but I don’t think it is wrong. > >> No, what can be done is to fix upstream's broken declaration that 'you can >> assume glib functions are available when doing "#include <gtk/gtk.h>"'. It >> doesn't follow that just because this works in practice, it should be a >> supported usage. > > When many of the types used by GTK+ are those provided by GLib, it > sounds wrong to ask developers to include the GLib headers to have these > types available. > Maybe so, but it doesn't excuse the rest. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: OpenPGP digital signature