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
makes such a transition more difficult. Unlike the normal dependency syntax, it is not possible to write something like
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.


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.

Reply via email to