| 1 |
On 27/05/16 16:40, 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 |
> (qa hat in place) |
| 23 |
> |
| 24 |
> There is a qa policy about this. All packages in the tree should |
| 25 |
> move away from the non-versioned gtk use flag to versioned use flags, |
| 26 |
> like the ones the qt team uses [1] [2]. |
| 27 |
> |
| 28 |
> This seems to be the best compromise. It allows the maintainers of the |
| 29 |
> packages to decide which toolkit they want to support. If there is too |
| 30 |
> much work involved in maintaining a package with dual support, don't do |
| 31 |
> the work, just make it support the appropriate toolkit version. |
| 32 |
> |
| 33 |
> I have not seen any reason why something like this couldn't work. After |
| 34 |
> all, it seems to work for the qt team. |
| 35 |
> |
| 36 |
> William |
| 37 |
> |
| 38 |
> [1] |
| 39 |
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#gtk.2Fgtk2.2Fgtk3_USE_flag_situation |
| 40 |
> [2] |
| 41 |
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#GTK_flag_situation |
| 42 |
Having read the QA policies, surely the route forwards is fairly obvious |
| 43 |
thus:- |
| 44 |
|
| 45 |
- gtk is deprecated and discouraged for any new ebuilds |
| 46 |
- we add a QA check to repoman to ensure that the 'gtk' use flag is not |
| 47 |
used in any new ebuilds |
| 48 |
- existing packages using 'gtk' will get updated to use 'gtk2' or 'gkt3' |
| 49 |
in the normal cycle |
| 50 |
|
| 51 |
Any edge cases here, or is this something that could be workable? |
| 52 |
|
| 53 |
MJE |
Archives