1 |
On Mon, 3 Aug 2015 00:34:51 +0800 Ben de Groot wrote: |
2 |
> Recently some team members of the Qt project have adopted these ebuild |
3 |
> policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies |
4 |
> |
5 |
> I have an issue with the policy adopted under "Requires one of two Qt |
6 |
> versions". In my opinion, in the case where a package offers a choice |
7 |
> between qt4 or qt5, we should express this in explicit useflags |
8 |
|
9 |
This is what the policy does: |
10 |
"Implement both qt4 and qt5 USE flags" |
11 |
|
12 |
> and a |
13 |
> REQUIRED_USE="^^ ( qt4 qt5 )". This offers the user the clearest choice. |
14 |
|
15 |
This will create insane amount of blockers if users have both flags |
16 |
in make.conf (and this is a common scenario). |
17 |
|
18 |
> Other developers state that users are not interested in such implementation |
19 |
> details, or that forced choice through REQUIRED_USE is too much of a |
20 |
> hassle. This results in current ebuilds such as quassel to not make it |
21 |
> clear that qt4 is an option. |
22 |
> |
23 |
> This goes against the principle of least surprise, as well as against QA |
24 |
> recommendations. I would like to hear specifically from QA about how we |
25 |
> should proceed, but comments from the wider developer community are also |
26 |
> welcome. |
27 |
|
28 |
As far as I understand this is done to simplify user's experiense: |
29 |
usually people set both USE="qt4 qt5" in global make.conf, because |
30 |
they want qt in the first place. |
31 |
|
32 |
This policy will allow to USE both qt versions whichever is |
33 |
available preferring newer one. Quite reasonable approach. |
34 |
Alternatives (^^() and ??()) will require micromanagement (e.g. |
35 |
pagkage.use.conf) for dozens if not hundreds of packages for no |
36 |
good reason. If someone still needs to override such policy (e.g. |
37 |
to use qt4 when both are available), this can be done by |
38 |
per-package configuration. |
39 |
|
40 |
My idea is that packages should be fully controllable, but choises |
41 |
of default behaviour should be done so, that in most cases |
42 |
micromanagement will not be necessary. |
43 |
|
44 |
I like this qt policy and I'm not sure if it violates any current |
45 |
rule. But even in such case this rule should be fixed. Moreover, |
46 |
this problem is not limited for qt: we have exactly the same issue |
47 |
with gtk2 vs gtk3 and probably some other technologies. |
48 |
|
49 |
Of course in theory it is possible to build package with two sets |
50 |
of binaries supporting both qt4 and qt5, but I see little practical |
51 |
need for that. |
52 |
|
53 |
So I propose to add somewhere to devmanual/policies the following |
54 |
recommendation: "If package supports several versions of the same |
55 |
technology (e.g. qt4 and qt5) and more than one is enabled by USE |
56 |
flags, ebuild should prefer the later one (in terms of technology |
57 |
generation).". |
58 |
|
59 |
Best regards, |
60 |
Andrew Savchenko |