[gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3

[gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3

[Andrey Grozin]

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

Re: [gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3

[Piotr Karbowski]

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.

Re: [gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3

[Andrey Grozin]

On Wed, 31 May 2023, Piotr Karbowski wrote:
> 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.
Yes, surely there are projects which work with 3.0 but not 3.2. But most 
projects will, probably, just work with 3.2. I've just switched 2 projects 
to 3.2 without negative consequences.

Andrey

Re: [gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3

[Mart Raudsepp]

Ühel kenal päeval, K, 31.05.2023 kell 11:43, kirjutas Andrey Grozin:
> 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.

I'm not aware what :*= is supposed to do, or if it's even valid syntax,
compared to := and :*

While yes, wxGTK does have implicit subslots from the subslot not being
specified (then the subslot is the same as the slot iirc), this isn't a
case of perl or similar. This is a case of python, ruby and similar, as
these are parallel-installable slots, where you would need to define
which they are OK with and lock to that then to avoid issues with other
deps using different wxGTK versions (for example imagine filezilla and
libfilezilla in a scenario where libfilezilla might grow a dependency
on wxCore at some point).

But with new slot versions happening every half or full decade, it
simply isn't worth adding such complexity. Instead everything should
try to switch to the newer version and stop using 3.0 ASAP. Optimizing
for users to be able to opt into using older buggier 3.0-gtk3 slot
instead of 3.2-gtk3 in order to not have to have multiple slots
installed isn't something that we should really worry about.

That said, we should indeed work towards updating consumers to 3.2-gtk3
now where possible, which should allow many users to go back to only a
single slot, or even from three slots to a single installed slot when
they had 3.0 and 3.0-gtk3 before.
I think you might have volunteered yourself for that, so you can
proceed ;)

Once the majority is in 3.0-gtk3, we can as a future step perhaps also
add 3.0 ones to package.deprecated.


Mart

Re: [gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

On Wed, 2023-05-31 at 11:43 +0000, 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

games-engines/odamex is another one that doesn't work with 3.2. It just
crashes. Haven't looked into it.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 858 bytes --]