On Mon, Apr 09, 2018 at 09:37:54PM +0100, Olly Betts wrote:

> I've read that ticket already, but I'm not really clear on why it
> requires the exact wxWidgets version.  If you built against wxWidgets
> then the real requirement is $upstream_version >= not
> $upstream_version == (or perhaps >= some lower version if there
> were no ABI additions since that version).
> Is there something more subtle here, or is this effectively an
> Alien::wxWidgets upstream design flaw which it's hard for distros to
> diverge from?

The latter I think. Upstream has decided to embed the wxWidgets version
(though with three digits not four, so 3.0.3) in the key used at runtime
to look up the build time configuration, creating a (possibly artificial)
requirement that they must match.

I guess we could patch it and/or file a wishlist bug upstream, but it
hasn't felt like a huge burden so far...

> > 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.
> If this is only because of the gtk2 to gtk3 switch, then this makes
> sense to me.  It's the first time this will have happened since we've
> had these two packages, and only the second time in 18 years we've
> changed toolkit in the default wxwidgets packages (previously gtk1 to
> gtk2).

Right. I think we can quite reasonably assume it's the toolkit switch.

We can revisit this if we run into other incompabilities in the future.

Reply via email to