[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: avant-window-navigator 0.2.1

On Sun, 2008-02-03 at 22:14 +0100, Cyril Brulebois wrote:
> On 03/02/2008, Neil Williams wrote:
> > What I meant was if dependencyA appears in the dpkg-shlibdeps list
> > of "not needed" linkages for 'foo' but foo is nearly always
> > installed alongside bar which uses symbols from dependencyA (i.e.
> > dpkg-shlibdeps doesn't complain about dependencyA in the build of
> > bar), then foo probably doesn't need to be altered. It's no
> > absolutely necessary for foo to Depend on dependencyA but it doesn't
> > hurt in the majority of cases.
> I now see your point, but I still disagree. Say foo depends on bar,
> bar depends on baz, and there's an extra link (hence Depends) between
> foo and baz. baz gets a bumped SONAME, bar gets rebuilt (through
> binNMUs). Fine. Err, no. foo has to be rebuilt as well. Too bad.

Ah, OK. I see that. The only time foo bears being rebuilt is if the
change in baz means that the rebuilt foo can drop that Depends (maybe
via an improved pkgconfig file in baz).

> > there are also cases where dpkg-shlibdeps reports an extra linkage
> > where the library concerned is already packaged alongside a library
> > that does need to be linked against the package - libdl is the most
> > common.
> I agree that there are some special cases, like libdl, pthreads, and
> so on. But ISTR that whole pages were reported by dpkg-shlibdeps, not
> only a few lines.

Very common with GUI packages. I'd like to be able to trim the
dependencies of libgpewidget at some point but the main problem is not
with libgpewidget itself but with the pkgconfig file it provides. This
adds libgtk+2.0-0 to each dependency of libgpewidget. What I really want
is to be able to use:
Requires: gtk+-2.0-minimal
Libs: -L${libdir} -lgpewidget
instead of:
Requires: gtk+-2.0
Libs: -L${libdir} -lgpewidget

/usr/lib/pkgconfig/gtk+-2.0-minimal.pc would then list:
Requires: gdk-${target}-2.0
instead of:
Requires: gdk-${target}-2.0 atk cairo

would support a -minimal that dropped the pango listing, etc. and maybe
a few others from the current:
Requires: gdk-pixbuf-2.0 cairo-directfb directfb  pango pangocairo 

then /usr/lib/pkgconfig/gdk-x11-2.0.pc could trim this list:
Requires: gdk-pixbuf-2.0  pango pangocairo

The problem is that these -minimal (and -extra) listings need to be
maintained within Gtk+, not libgpewidget.

I could just patch the libgpewidget.pc file (adding -lgtk2.0-0 to --libs
and replacing the Requires:) but I need the time to test the entire GPE
package set using that setup *and* cross build the whole set before I
can deploy such a change, it's just too disruptive to start on before
Lenny (what with the Lenny soft freeze being less than a month hence).

Just imagine the chaos in Debian if the pkgconfig data of libgtk+2.0-0
was changed now. Each reverse dependency would then need upstream
changes to add extra libs to the build that were previously implied.
That would be just as disruptive as a full SONAME transition in Gtk+
itself - how long is it now since gtk1 became gtk2? Adding a new pc file
is the only realistic method that I can see because it supports all
builds, not just Debian and the migration can be done incrementally.

These kind of things have implications far beyond the current package
but this is, IMHO, TheRightWay(tm) to fix things, not using

> > Now I'm all in favour of reducing spurious dependencies - as anyone
> > would expect whilst working on making Debian small enough for
> > embedded devices - but not at the cost of making more work for
> > myself when cross building the same package. I just want to be sure
> > the changes actually work before recommending them to others. IMHO,
> > -Wl,--as-needed -Wl,zdefs is not at that stage, yet.
> In the thread (on -devel) where the use of those options were
> discussed, I don't remind of people reporting broken packages due to
> that. But if you could find examples of broken packages because of
> that, I'm very interested (in having a look and eventually fixing them
> if I can do that).

I will, thanks.

In the meantime, I think it's worth being cautious about recommending
trimming of dependencies. Maybe applications can be trimmed without too
many consequences but I wouldn't advise trimming the dependencies of a
library (or library pkgconfig file) on mentors - which is a problem
because it is with libraries where the benefits of trimming are most


Neil Williams

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: