Bug#895134: libwx-scintilla-perl: needs tighter dependency on Wx build?

[Niko Tyni]

On Sat, Apr 07, 2018 at 09:57:15PM +0100, Olly Betts wrote:
> On Sat, Apr 07, 2018 at 04:20:48PM +0300, Niko Tyni wrote:
> > 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
> any other -perl packages in the transition tracker:

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
> all release archs:
> 
> 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