Re: Candidates for removal from testing (2012-11-30)
On 30/11/12 11:55, Niels Thykier wrote:
> The packages have been selected based on the following criteria: *
> The package had at least one RC bug without activity for the past
> 14 days.
...
> Debian GNOME Maintainers
> <pkg-gnome-maintainers@lists.alioth.debian.org> gnome-dvb-daemon
> (U)
I have no particular interest in gnome-dvb-daemon, but if it works
correctly on those architectures that can build it, I think it
deserves to remain in testing.
Its RC bugs are duplicate FTBFSs, which aren't really a
gnome-dvb-daemon bug: it's a victim of #674156, a long-standing[1] ABI
break in glib2.0 on 32-bit non-x86 architectures, and will probably
build successfully once that has been resolved.
Discussion of how best to resolve that bug (#694525, and further
discussion in #debian-gnome) was inconclusive: none of the options are
actually good, so it's a matter of choosing the least bad.
Suggested options include:
A) Consider the new ABI to be "right". Recompile every package that
mentions the affected structs (including everything that
subclasses GstElement), unless it has already been compiled
against GLib 2.32 on every architecture.
+: Every frequently-uploaded package, including large ones like
Webkit, Qt and the Mozilla suite, have already been compiled
against GLib 2.32 in practice anyway. The most significant
exception that I noticed is GStreamer 0.10, which is where we
noticed this ABI break: the problem is that "core" GStreamer has
not been recompiled since, but some packages that subclass its
objects have.
-: Binaries built against squeeze's GLib on the affected
architectures will break, in relatively rare circumstances[2].
We have to recompile up to 227 source packages.
B) Consider the old ABI to be "right". Recompile every package that
mentions the affected structs, unless it has never been compiled
against GLib 2.32 on any architecture.
+: Binaries built against squeeze's GLib will not break.
-: Binaries built against anyone else's GLib (most notably the
increasingly popular ARM ports of other distributions, e.g.
Fedora, Ubuntu, Raspbian) will break on Debian in
relatively rare circumstances[2]. We have to carry the patch
for the lifetime of libglib2.0.so.0, otherwise we might
as well have done (A). We have to recompile an unknown
number of source packages, including Webkit, Qt and the
Mozilla suite; the longer we think about it for, the larger this
number gets.
C) Change GLib's package name and/or SONAME. Recompile literally every
package that depends on GLib.
+: Parallel-installable with squeeze's GLib. Existing binaries
built by stable users continue to work. Existing binaries built
by testing/unstable users are no more broken than they already
are.
-: Our ABI diverges from upstream for every GLib user (not just
those that use the affected structs, or are on the affected
architectures) for the lifetime of libglib2.0.so.0. Binaries
built against anyone else's GLib will not have their
dependencies met in Debian and vice versa. We have to
recompile 903 source packages, if my count is correct.
When I say "recompile", what I mean is:
* If the source does not build Multi-Arch:same packages, binNMU it.
In strategies A and B, in most cases it's probably not worth taking
the time to audit whether it is actually affected, or whether it has
already been built with the right GLib on every architecture: buildd
time is less limited than developer time.
* If following strategy A or B, check whether it's actually affected
and whether it's already been built with the right GLib on every
architecture; if following strategy C, it needs rebuilding anyway.
If an upload is needed, make a sourceful upload.
I personally think the order of desirability is (A) > (B) >> (C), but
I have tried to give an unbiased summary of each option.
----
[1] By "long-standing" I mean: upstream master since September 2011,
upstream stable releases since March 2012, Debian unstable also since
March 2012, Debian testing since at least April 2012.
[2] The "rare circumstances" under which breakage occurs are:
* the architecture ABI gives doubles greater alignment than the size
of a pointer. In practice this means 32-bit RISC: arm*, mips*,
powerpc, s390, sparc.
* a package (typically gstreamer0.10) defines a struct in its public
header which contains a GStaticMutex, GStaticRecMutex or GStaticRWLock
(the most prominent example is GstElement)
* package P1 (typically an implementor of GStreamer plugins) embeds
that struct in a larger struct (typically a GstElement subclass)
* package P2, which might be gstreamer0.10 or a third package, looks
at members of the larger struct that appear after the GStaticWhatever.
GObject has a built-in check for this: it issues a warning if
subclasses think they're smaller than their parent class.
* of packages P1 and P2, one was compiled with GLib < 2.32 and the
other was compiled with GLib >= 2.32
Reply to: