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

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

   -: 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: