On 01/01/13 13:26, Julien Cristau wrote:
> On Sun, Dec 30, 2012 at 23:28:13 +0000, Simon McVittie wrote:
>> I've only tested this fairly trivially (totem still plays
>> videos); I'll do some more testing before uploading if it becomes
>> necessary, but it'd be better if a maintainer could do proper
>> testing and a MU.
Any maintainer opinions on this?
> This seems to be missing a way to ensure plugins get a dependency
> on the rebuilt libgstreamer0.10-0 (or whatever else is needed to
> prevent the combination of a gstreamer and plugin that disagree on
> the size of structs)?
As far as I can work out, bumping libgstreamer0.10-0's shlibs would only
help to achieve this if we additionally NMU a bunch of packages to
rebuild them against the new libgstreamer0.10-0 so they get a
dependency. Some of them are multiarch and would thus need a sourceful
upload (gst-plugins-*0.10, *farstream*, etc.) so that doesn't seem
ideal; most of the affected packages have the new ABI already.
One alternative would be for libgstreamer0.10-0 to have versioned Breaks
on those packages, which would reduce the number of uploads considerably.
Another alternative would be to add Breaks to libglib2.0-0 and rely on
the fact that a newly-built libgstreamer0.10-0 already picks up
Depends: libglib2.0-0 (>> squeeze's), and so squeeze-to-wheezy partial
upgrades that pull in the new libgstreamer0.10-0 also pull in the new
libglib2.0-0, which forces the other affected packages to be upgraded
or removed.
The broken situation is in this dependency chain:
libglib2.0-0 <- libgstreamer0.10-0 <- third-package
with this embedding:
struct ThirdPackageThing {
...
struct GstThing {
...
struct GStaticMutex;
...
}
...
}
Let's call anything that encodes the old (glib2.0 << 2.32) size of
GStaticMutex "old", and anything that encodes the new (glib2.0 >= 2.32)
size of GStaticMutex "new".
The binaries in libgstreamer0.10-0 are either "old" or "new" depending
on their interpretation of their own headers. That interpretation
depends on the version of libglib2.0-dev, "old" or "new", that was
installed when they were compiled.
The binaries in third-package are either "old" or "new", depending on
their interpretation of GStreamer's headers. That interpretation depends
only on the version of libglib2.0-dev that was installed at the time
they were compiled; it does not depend on the version of
libgstreamer0.10-dev that was installed at the time they were compiled.
This is because, in the usual C way, the Gst headers don't explicitly
say what the size of GstThing is: they only define it in terms of the
size of GStaticMutex, and the compiler does the arithmetic anew while
building each translation unit.
(This is how we can have third-level packages appearing in the "new"
set, even though no "new" version of gstreamer0.10 exists yet.)
The broken situation is that at runtime, you have a "new" libglib2.0-0,
an "old" libgstreamer0.10-0, and a "new" third-package.
AFAICS, a big pile of versioned Breaks from libglib2.0-0 to packages
that are known to be affected and built with "old" GLib would resolve
this. I'm somewhat concerned that that many versioned Breaks are going
to make the apt resolver work harder, and might themselves break the
full-upgrade process (like #676485).
I believe that can be mitigated by making the versioned Breaks specific
to the affected architectures, which would result in no additional
upgrade problems for users of unaffected architectures - but in practice
I don't think anyone ever runs piuparts on the affected architectures,
making it harder for any upgrade problems to be discovered.
Regards,
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
