Hi,
On 31/05/2023 13.43, Andrey Grozin wrote:
Hello *,
wxGTK:3.2-gtk3 is now stable. But there are 98 ebuilds depending on
wxGTK:3.0-gtk3 and only 22 ebuilds depending on wxGTK:3.2-gtk3 in the
tree. Probably, in a vast majority of cases 3.0 can be simply replaced
by 3.2 without any negative consequences. What could be a reasonable way
to organize the transition 3.0 -> 3.2 in the tree? File a zillion bugs?
The fact that this dependence is written in a special syntax
WX_GTK_VER="3.0-gtk3"
makes such a transition more difficult. Unlike the normal dependency
syntax, it is not possible to write something like
x11-libs/wxGTK:*=
This is unfortunate. The 3.0 -> 3.2 transition absolutely requires to
edit ebuild texts, unlike :*= where the same ebuild can work with
different slots (just a recompilation is sufficient for transition).
This fact makes it impossible for an ebuild to work with both slots. In
a majority of cases, I suppose, it would be desirable to allow an ebuild
to work with any of these 2 slots, without a necessity to edit it. But,
alas, this is not possible.
Andrey
There's at least a few project that will not work with new wxGTK, out of
what I know that is in tree the SuperSlicer and the PrusaSlicer that in
the version currently in tree requires wxGTK 3.0. The newer version of
PrusaSlicer actually requires wxGTK 3.1 and does not work well with 3.2,
unless the wxGTK 3.2 is built with '--disable-glcanvasegl', but this is
not interfaced as USE flag and I doubt ever will be.
Filling bugs might be the way to go, but please keep in mind that some
software might be borderline impossible to switch to new wxGTK therefore
a 3.0 would need to stay in tree for extended period of time.
-- Piotr.
