Re: Bug#520642: gtk2-engines-udeb: depends on non-udeb packages on hppa, among other things
* Josselin Mouette [Sat, 21 Mar 2009 16:57:46 +0100]:
> Le samedi 21 mars 2009 à 15:34 +0100, Adeodato Simó a écrit :
> > gtk2-engines-udeb exhibits two problems on hppa, though the second of
> > them may be applicable to other arches as well.
> > In the first place, gtk2-engines-udeb 2.14.3-2 and 2.16.1-2 depend on
> > libdirectfb-1.0-0-udeb, but only on hppa. This dependency is,
> > additionally, spurious: the files shipped in gtk2-engines-udeb are
> > linked against libdirectfb-1.0, but do not use any of its symbols as far
> > as I can see. The fact that this linkage is only present on hppa is
> > probably symptomatic that something is going wrong there.
> This looks like a binutils bug on hppa to me. In both 2.16.1-2 and
> 2.16.1-2+b1, the engines end up with a NEEDED on directfb, while the
> link line is:
> cc -shared .libs/clearlooks_rc_style.o .libs/clearlooks_style.o .libs/clearlooks_theme_main.o .libs/support.o .libs/animation.o .libs/clearlooks_draw.o .libs/clearlooks_draw_glossy.o .libs/clearlooks_draw_inverted.o .libs/clearlooks_draw_gummy.o -Wl,--whole-archive ../../engines/support/.libs/libsupport.a -Wl,--no-whole-archive -Wl,--as-needed -lgtk-directfb-2.0 -lgdk-directfb-2.0 -ldirectfb -lfusion -ldirect -lpthread /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangocairo-1.0.so /usr/lib/libgio-2.0.so /usr/lib/libpango-1.0.so /usr/lib/libcairo.so /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so /usr/lib/libglib-2.0.so -Wl,-z -Wl,defs -Wl,-O1 -Wl,-Bsymbolic -Wl,-soname -Wl,libclearlooks.so -o .libs/libclearlooks.so
> So this is a problem with --as-needed. Not a trivial one, since it works
> with a trivial test case – just checked on paer which has the same
> binutils version (2.19.1-1).
Okay. Well, not a big deal I guess, just a spurious dependency.
> > This dependency on directfb caused us to schedule a Bin-NMU of
> > gtk2-engines on hppa in order to rebuild it against the new directfb.
> > Which brings us to the second problem: the resulting gtk2-engines-udeb
> > 2.16.1-2+b1 has completely fucked up dependencies! It depends on
> > libcairo2, libglib2.0-0 and libgtk2.0-0 instead of their -udeb
> > counterparts!
> The explanation is simple: these packages have fscked up shlibs files on
> hppa, without udeb lines. This is caused by #518706.
> dh_makeshlibs -plibgtk2.0-0 \
> -Xusr/lib/gtk-2.0/2.10.0 \
> -V"libgtk2.0-0 (>= 2.14.0)" \
> --add-udeb=libgtk-directfb-2.0-0-udeb
> Option add-udeb does not take an argument
> My take on it is: binNMU *in order* glib2.0, directfb, cairo, gtk+2.0
> and gtk2-engines on hppa.
Uhm, this is very problematic. Thanks for the heads up, Joss. Let’s work
together with -boot now, because their input is going to be indispensable
in order to ensure we completely fix the problem.
There are two parts to the problem: (a) packages with buggy shlibs
files, and (b) packages with buggy dependencies. (Some packages are in
both groups.) Let’s take group (b) first; Joss, you can skip this part
and go for group (a) below.
So, for group (b), I tried to guess which packages need a rebuild. My
lack of knowledge about d-i internals made me believe that all udebs
should be depending on other udebs only, but this seems not to be the
case.
So I went for a list of udebs in unstable that depend on non-udebs,
except those dependencies already in stable. The results are mostly in
hppa, and mostly related to the directfb transition. So, on hppa:
package | dependency
-----------------------------+-----------------------
cdebconf-gtk-udeb | libcairo2
| libdirectfb-1.2-0
| libglib2.0-0
| libgtk2.0-0
| libgtk-directfb-2.0-0
|
cdebconf-gtk-entropy | libcairo2
| libdirectfb-1.2-0
| libglib2.0-0
| libgtk2.0-0
| libgtk-directfb-2.0-0
|
cdebconf-gtk-terminal | libcairo2
| libdirectfb-1.2-0
| libglib2.0-0
| libgtk2.0-0
| libgtk-directfb-2.0-0
|
gtk2-engines-udeb | libcairo2
| libdirectfb-1.2-0
| libglib2.0-0
| libgtk2.0-0
| libgtk-directfb-2.0-0
|
libdirectfb-bin-udeb | libdirectfb-1.2-0
|
libcairo-directfb2-udeb | libdirectfb-1.2-0
|
libgtk-directfb-2.0-0-udeb | libcairo2
| libdirectfb-1.2-0
libsdl1.2debian-udeb | libdirectfb-1.2-0
|
libvte9-udeb | libcairo2
| libdirectfb-1.2-0
| libglib2.0-0
| libgtk2.0-0
| libgtk-directfb-2.0-0
So all these will need Bin-NMUs. Additionally, I’d like to draw your
attention on the following ones, so that you can assess whether rebuilds
are needed.
package | arch | dep
----------------------------+-------+-----------------------
libpcre3-udeb | i386 | libc6
libdirectfb-1.2-0-udeb | armel | libgcc1
libdmraid1.0.0.rc15-udeb | armel | libgcc1
dmraid-udeb | hppa | 1
(Yes, dmraid-udeb depends on a package named “1” on hppa...)
So, -boot, please let us know if you have ways to detect further
breakage, and we can see about that.
---
Regarding group (a), packages with broken shlibs files, they are at
least glib, directfb, cairo and gtk+2.0 on hppa *that we know of*. We
have no easy way of determining which other packages may be affected by
having being built with #518706.
So I guess we can start by Bin-NMUing those, but suggestions about how
to detect further breakage are welcome.
Joss, in particular about glib2.0, though, I don’t see anything broken
in its current shlibs file, which includes lines in the form:
udeb: libgobject-2.0 0 libglib2.0-udeb (>= 2.20.0)
udeb: libglib-2.0 0 libglib2.0-udeb (>= 2.20.0)
udeb: libgmodule-2.0 0 libglib2.0-udeb (>= 2.20.0)
udeb: libgio-2.0 0 libglib2.0-udeb (>= 2.20.0)
udeb: libgthread-2.0 0 libglib2.0-udeb (>= 2.20.0)
I’m guessing it was 2.20.0-1 that was affected. The other three are
definitely affected.
---
So, next actions:
* I schedule Bin-NMUs of directfb, cairo, gtk+2.0 on hppa to fix their
shlibs files, with appropriate dep-waits.
* I schedule Bin-NMUs of cdebconf-{,-entropy,-terminal}, gtk2-engines,
libsdl1.2 and libvte on hppa dep-waited on the Bin-NMUs above.
* I do nothing about pcre3 and dmraid unless told otherwise by -boot
* I wait for ideas, if any, to detect if any other packages have
broken shlibs files regarding udebs.
Cheers,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
Reply to: