1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 02/11/2014 06:13 PM, Gilles Dartiguelongue wrote: |
5 |
> Thanks for attaching link to team's policy which tries to lift any |
6 |
> kind of ambiguities people may have for what concerns gnome team's |
7 |
> packages, I hope it proved useful in your discussions. |
8 |
> |
9 |
> |
10 |
> Le mercredi 12 février 2014 à 00:39 +0200, Alex Alexander a écrit |
11 |
> : |
12 |
>> Hello fellow developers, |
13 |
>> |
14 |
>> In the first meeting of the new QA team, we discussed the state |
15 |
>> of the gtk{,2,3} USE flags in the main tree. [0] |
16 |
>> |
17 |
>> In its current state, USE="gtk" means gtk2. The Gnome team is |
18 |
>> trying to change this into "the most recent gtk version" (it is a |
19 |
>> work in progress). |
20 |
> |
21 |
> Wrong, gtk USE flag means "enable gtk support", whether this is gtk |
22 |
> 1, 2 or 3 depends on what the package (presumably library) supports |
23 |
> and whether is can be slotted or not and whether current gentoo |
24 |
> maintainer decides what can be reasonably supported. |
25 |
> |
26 |
>> Unfortunately, the concurrent nature of gtk2/gtk3 has resulted in |
27 |
>> packages that may support either or both the toolkits. To handle |
28 |
>> this, a few developers have introduced the "gtk3" useflag, that |
29 |
>> prefers gtk3 over gtk2 when both toolkit versions are supported. |
30 |
>> At this point, the Gnome team highly recommends prefering gtk3 if |
31 |
>> possible, skipping the useflag altogether. [1] |
32 |
> |
33 |
> Wrong, as is written in policy whether to prefer gtk2 or 3 is up to |
34 |
> the maintainer of the package. We point people to the fact that |
35 |
> upstream says gtk2 is a dead end and support will stop (if not in |
36 |
> fact already stopped) in the near future. |
37 |
> |
38 |
> We also recommend to have maintainers support slots for their libs |
39 |
> where possible considering man-power and to only choose one toolkit |
40 |
> for applications considering where upstream development is going |
41 |
> and maturity of the port, and again, this is up to package |
42 |
> maintainers. |
43 |
This doesn't make sense to me at all. I can't see why slotted |
44 |
libraries can't just use USE flags to specify what toolkit they're |
45 |
built against, just like any other package in the tree (so, for |
46 |
example, a package that needs webkit-gtk built against gtk3 would |
47 |
depend on webkit-gtk[gtk3] instead of webkit-gtk:3). I'm well aware |
48 |
that there could be limitations I'm unaware of (maybe the package only |
49 |
can build one at a time?), but this is how it looks to me. By |
50 |
switching to versioned gtk flags, this kills two birds with one stone: |
51 |
it makes it obvious to the end user which version they're trying to |
52 |
build their package against, and it gets rid of the need for (ab)using |
53 |
revision numbers to implement slots like that. |
54 |
|
55 |
> |
56 |
>> Some developers choose to follow the Gnome team's highlights, |
57 |
>> while others choose to go their own way. The QA team would like |
58 |
>> to establish a guideline that solves this problem in the best way |
59 |
>> possible. |
60 |
>> |
61 |
>> During our discussion, it was pointed out that keeping a generic |
62 |
>> USE="gtk" is sub-optimal. The non-straightforward nature of new |
63 |
>> toolkit versions makes transitioning from one to the other a |
64 |
>> slow, tedius process and we think that a non-versioned USE flag |
65 |
>> makes things even worse. |
66 |
>> |
67 |
>> A few of our members recommended a move away from the unversioned |
68 |
>> USE="gtk" to versioned-only USE flags. Qt managed to do this |
69 |
>> quite successfully when they transitioned from the unversioned |
70 |
>> USE="qt" (that actually meant qt3) to USE="qt4". The benefits can |
71 |
>> be seen now that qt5 is around the corner. USE="qt5" is |
72 |
>> straightforward, does not mess with qt4 packages and was |
73 |
>> introduced to the tree without messing with current packages too |
74 |
>> much - other than adding a new use flag where appropriate. There |
75 |
>> is also no need for USE="qt" anymore. |
76 |
>> |
77 |
>> To achieve this, version 3 of gtk should always be enabled by |
78 |
>> USE="gtk3". At some point in the future, when gtk2 consumers |
79 |
>> reach zero, we will retire "gtk" for good. Then, if some day gtk4 |
80 |
>> comes around, we will be able to introduce support for it in the |
81 |
>> tree by simply adding USE="gtk4", without having to re-structure |
82 |
>> half the tree. |
83 |
>> |
84 |
>> We are reaching out to the developer community to hear your |
85 |
>> thoughts and ideas on the matter. We would like to reach a |
86 |
>> decision that could possibly affect and direct the state of whole |
87 |
>> tree. This decision could then be turned into a policy, improving |
88 |
>> Gentoo's consistency across the tree. |
89 |
> |
90 |
> Imho the whole discussion stems for packages maintainers which, as |
91 |
> you have written, did not follow our recommendation and tried to |
92 |
> provided application with both gtk2 and gtk3 support. |
93 |
> |
94 |
> I agree that "Gentoo is about choice..." however as a maintainer of |
95 |
> a lot of packages, it is unreasonable to try to support two |
96 |
> configuration where one is dying slowly due to upstream (gtk) |
97 |
> maintainer focus being elsewhere, hence why we wanted maintainers |
98 |
> to choose. Instead, it occurs that some decided not to choose or to |
99 |
> stop users from annoying them with 100 of duplicate bugs about not |
100 |
> providing the alternative. |
101 |
> |
102 |
> Looking at the situation from a gnome team member perspective when |
103 |
> Gnome 3 was introduced to the tree, only three packages (providing |
104 |
> libs) needed exception to the rule to avoid unreasonable |
105 |
> maintenance overhead: spice, gtk-vnc and avahi. All of them had |
106 |
> proper USE-dependencies in relevant ebuilds so no confusion would |
107 |
> be possible. |
108 |
> |
109 |
> Right now, I don't really get the point of this discussion given |
110 |
> all the precedent threads about this, be it 2 years ago and 8-10 |
111 |
> years ago. |
112 |
> |
113 |
> Anyway, if QA would provide with a list of "offenders" (this could |
114 |
> have been done on bugzilla btw), we could walk-through the list and |
115 |
> verify what/if/how packages would need extra USE flags or not and |
116 |
> not just for our self-written policy's sake that is. |
117 |
> |
118 |
>> Cheers |
119 |
>> |
120 |
>> [0] |
121 |
>> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Summary_of_Wednesday_January_29.2C_2014 |
122 |
>> |
123 |
>> |
124 |
[1] https://wiki.gentoo.org/wiki/Gnome_Team_Policies#gtk3 |
125 |
> |
126 |
|
127 |
-----BEGIN PGP SIGNATURE----- |
128 |
Version: GnuPG v2.0.22 (GNU/Linux) |
129 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
130 |
|
131 |
iKYEARECAGYFAlL6wUJfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl |
132 |
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC |
133 |
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1Q2IACeOB96oRQ5Q0xPrmSumpHePAs8 |
134 |
j/wAmwZYD20RaNaswb8rzRQCyqTw9ya9 |
135 |
=tQvv |
136 |
-----END PGP SIGNATURE----- |