Re: [gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3
On Wed, 2023-05-31 at 11: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 games-engines/odamex is another one that doesn't work with 3.2. It just crashes. Haven't looked into it. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3
Ü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
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
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.
