Ü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

Reply via email to