1 |
On 05/27/2016 11:40 AM, William Hubbs wrote: |
2 |
> On Fri, May 27, 2016 at 05:21:06PM +0300, Mart Raudsepp wrote: |
3 |
>> Hello, |
4 |
>> |
5 |
>> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten |
6 |
>> upstream, many applications still support only gtk2, have subtle issues |
7 |
>> with their gtk3 port, or support both, with some of our userbase |
8 |
>> clinging to gtk2 for dubious political or aesthetical reasons. |
9 |
>> |
10 |
>> For the latter cases, despite GNOME teams policy and strong preference |
11 |
>> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's |
12 |
>> working as good as gtk2), some cases exist where the maintainers want |
13 |
>> to provide such choice. In some cases it is understandable for a short |
14 |
>> while during transition, e.g firefox. In other cases, it is purely for |
15 |
>> the sake of providing the choice of working with a deprecated toolkit, |
16 |
>> apparently. |
17 |
>> |
18 |
>> My highly biased essay aside, we need to finally globally agree on what |
19 |
>> we do in this situation. If we allow this choice at all, only for |
20 |
>> special cases, or widespread. And if this choice is provided, how do we |
21 |
>> name the USE flag. |
22 |
> |
23 |
> (qa hat in place) |
24 |
> |
25 |
> There is a qa policy about this. All packages in the tree should |
26 |
> move away from the non-versioned gtk use flag to versioned use flags, |
27 |
> like the ones the qt team uses [1] [2]. |
28 |
> |
29 |
> This seems to be the best compromise. It allows the maintainers of the |
30 |
> packages to decide which toolkit they want to support. If there is too |
31 |
> much work involved in maintaining a package with dual support, don't do |
32 |
> the work, just make it support the appropriate toolkit version. |
33 |
> |
34 |
> I have not seen any reason why something like this couldn't work. After |
35 |
> all, it seems to work for the qt team. |
36 |
> |
37 |
> William |
38 |
> |
39 |
> [1] |
40 |
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#gtk.2Fgtk2.2Fgtk3_USE_flag_situation |
41 |
> [2] |
42 |
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#GTK_flag_situation |
43 |
> |
44 |
|
45 |
Explicit gtk version flags is fine by me: |
46 |
REQUIRED_USE=" || ( gtk2 gtk3 ) ^^ ( gtk2 gtk3 ) ?? ( gtk2 gtk3 )" |
47 |
|
48 |
I think an unversioned gtk flag semantically makes and simplifies some |
49 |
ebuild logic in cases where gtk support is completely optional. |
50 |
DEPEND=" |
51 |
gtk? ( |
52 |
cat/foo |
53 |
cat/gorp[gtk2=,gtk3=] |
54 |
gtk2? ( |
55 |
cat/bar:2 |
56 |
cat/baz[gtk2] |
57 |
x11-misc/gtk:2 |
58 |
) |
59 |
gtk3? ( |
60 |
cat/bar:3 |
61 |
x11-misc/gtk:3 |
62 |
) |
63 |
) |
64 |
" |
65 |
|
66 |
So, in summary, I'm content to move away from unversioned gtk flags in |
67 |
all cases except when using it to describe "optional gtk support" which |
68 |
is then backed up with versioned gtk flags. |
69 |
|
70 |
Also, regardless of the decision, I'd be happy to help refactor the tree |
71 |
to conform with the decision. |
72 |
-- |
73 |
NP-Hardass |