Ü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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)