1 |
On Tue, Aug 11, 2015 at 3:13 PM, Gregory Woodbury <redwolfe@×××××.com> wrote: |
2 |
> Is a possible solution something like an eselect module to indicate |
3 |
> the preferred |
4 |
> interface kit? It could default to any package that is available with |
5 |
> a sequential |
6 |
> set of preferred order. |
7 |
> Then ebuild would consult the eselect module, and users who care can |
8 |
> select the kit they want, and users who don't care/know get the default. |
9 |
|
10 |
That still neglects the case where a user just wanted to say "use the |
11 |
best version of qt for any particular package," which I'd argue is |
12 |
probably the most common use case. It may not make sense to have one |
13 |
global preference system-wide, and managing it per-package is painful. |
14 |
It really does make sense to leave it up to the maintainer, while |
15 |
still letting people either turn off qt entirely if they'd prefer to |
16 |
do so, or override the default implementation when they really want |
17 |
to. |
18 |
|
19 |
There is always requiring any package that supports qt to enable |
20 |
either qt4 or qt5 by default, so the typical user who wants qt does |
21 |
nothing, the typical user who doesn't want qt sets USE="-qt4 -qt5", |
22 |
and then anybody who wants to override things per-package can do so. |
23 |
That is simple to define in ebuilds, and you can set REQUIRED_USE to |
24 |
prevent them both from being set. It just means having qt support by |
25 |
default all over the tree and forcing people who don't want it to |
26 |
explicitly turn it off. That is simple to do at least, but not really |
27 |
in keeping with the general spirit of the base profile being a minimal |
28 |
one. And it would still be difficult to do anything at the profile |
29 |
level if it were appropriate to do so. |
30 |
|
31 |
-- |
32 |
Rich |