So to do this properly it looks like we need something to make
sure the Perl Wx related packages are upgraded in sync. The
virtual package provided by libalien-wxwidgets-perl (currently
wxperl-gtk-3-0-4-uni-gcc-3-4) seems like a candidate, but I don't have
a ready recipe for injecting that.
I'd guess that makes sense, but I don't entirely understand how the
libalien-wxwidgets-perl <-> libwx-perl connection works, or why we need
a chain of binNMUs after each new upstream wxwidgets3.0 release.
AIUI Alien::wxWidgets provides information about a wxwidgets installation,
and libwx-perl uses that to offer machinery for building wxwidgets
related Perl packages (the Wx::build namespace.) This build machinery
embeds the exact wxwidgets version/configuration from Alien::wxWidgets,
and breaks if those get out of sync. Hence the binNMU requirement. See
#757855 for the full story.
So the tight coupling is only for the Wx::build machinery. As we see in
this bug, no such extra provisions currently exist for keeping Wx based
binary Perl code (lke libwx-scintilla-perl) in sync with the Wx bindings
(libwx-perl).
Presumably just copying libwx-perl's dependencies related to this
across would work?
Yeah, if we accept the burden of rebuilding libwx-scintilla-perl and
libwx-glcanvas-perl too on every wxwidgets3.0 upstream release.
Alternatively I guess either libwx-perl or libalien-wxwidgets-perl
could Provide another less finely grained virtual package that
only encodes those parts that are expected to be incompatible at
run time, like wxperl-gtk3 or something like that. But that feels
overkill.
Another approach would be to consider this a one time glitch (how often
are we going to change toolkits anyway?), make libwx-perl Break older
(gtk2 based) libwx-scintilla-perl and libwx-glcanvas-perl versions,
and have those packages in turn depend on newer (gtk3 based) libwx-perl
versions. That should handle it afaics.
It seems probable that other packages (libwx-glcanvas-perl?) are
similarly affected, but I haven't looked into that.
I'd expect so. There don't seem to be any others - at least I don't see
I think those are the only two Wx perl packages we have with compiled
C extensions ("XS").
I didn't try to handle preventing combinations of new libwx-perl with
older libwx-scintilla-perl or libwx-glcanvas-perl though since there was
no evidence that such handling was attempted for previous transitions.
Either they haven't broken partial upgrades earlier, or we just haven't
noticed that.
Setting severity to RC initially and marking as a transition blocker,
but others should feel free to adjust as appropriate.
It would certainly be good to address this somehow, but mostly because
it will ease future transitions. I'm not sure this really deserves to
block this one as the libwx*-perl collection is now back in step across
https://buildd.debian.org/status/package.php?p=libalien-wxwidgets-perl+libwx-perl+libwx-scintilla-perl+libwx-glcanvas-perl
Also blocking the transition really just means that the wx gtk2 packages
can't be removed, yet doing that if anything improves the situation.
But that's mostly a theoretical point right now as the full transition
is going to take months.
Yeah. FWIW I don't think the transition blocker metadata technically
affects testing migration or wx gtk2 binary removal. I intended it just
as a note for humans that these issues are linked. Naturally I'm fine
with removing it if it gets in the way for anybody.
As for whether this needs to be fixed or not: I think the minimum
requirement in the release criticality sense is that partial upgrades
between stable releases stay working. I expect we'll be rebuilding
libwx-scintilla-perl and libwx-glcanvas-perl for at least Perl 5.28
before the buster release anyway, so that will probably take care of it
(because both libwx-perl and libwx-scintilla-perl will then be necessarily
upgraded in lockstep with Perl itself.)
Of course, keeping partial upgrades working for users of testing and
Debian derivatives is a worthy goal too.
--
Niko