Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: useflag policies
Date: Tue, 04 Aug 2015 06:05:50
Message-Id: pan$37062$8d67250c$a38989a8$3521326d@cox.net
In Reply to: Re: [gentoo-dev] useflag policies by Ben de Groot
1 Ben de Groot posted on Tue, 04 Aug 2015 11:59:40 +0800 as excerpted:
2
3 > In my opinion, this is the way Gentoo has always worked, and we should
4 > simply recommend users to only set one of the qt* useflags as globally
5 > enabled, if they want to prevent such micro-management. Hiding the qt4
6 > option is in my opinion the wrong solution around people complaining
7 > after they have consciously enabled both flags.
8 >
9 > If this is not acceptable (or "absolutely unusable" as one dev put it),
10 > then we need a proper solution, which a) will not hide the qt4 option,
11 > and b) will prevent triggering required_use blockage by choosing qt5
12 > over qt4 in case both are enabled, while c) informing the user about
13 > this. This probably requires new eclass or even EAPI functionality.
14
15 What about a solution such as that used by python, USE=qt, for turning on
16 qt support at all if it's optional, with QT_TARGETS for people to set to
17 the versions they want if more than one can be enabled at once, and
18 QT_SINGLE_TARGET for people to set to their preferred if a package can
19 build against only one at a time, but that one can be chosen?
20
21 And of course, just as with python, people can setup an /etc/portage/env/
22 * file for exceptions, and point as many packages at that file as desired
23 using package.env.[1]
24
25 But this would be dramatically simpler with qt than it is with python,
26 since there will normally only be two (with a theoretical but unlikely
27 possibility of three) choices at the same time, and the time between qt
28 slot upgrades and slot-effective times as well is much /much/ longer than
29 between python slot upgrades.
30
31 Of course it'd require a whole new set of eclasses, but it's not as if
32 that hasn't been done before.
33
34 [1] FWIW, that's the python solution I've been using for awhile, with
35 PYTHON_SINGLE_TARGET set to 3.3 and then 3.4 in make.conf, with an
36 /etc/portage/env/python.starget.27 file that does what the name suggests,
37 and formerly quite a few package entries in /etc/portage/package.env
38 pointing to it that couldn't handle python3 yet, but now only one, app-
39 text/asciidoc.
40
41 --
42 Duncan - List replies preferred. No HTML msgs.
43 "Every nonfree program has a lord, a master --
44 and if you use the program, he is your master." Richard Stallman