1 |
On Tue, 20 Jun 2006 16:14:08 -0700 |
2 |
Donnie Berkholz <spyderous@g.o> wrote: |
3 |
|
4 |
> Mike Owen wrote: |
5 |
> > From this user's perspective, simple is better. qt3 and qt4 as use |
6 |
> > flags are completely and utterly obvious as to what they mean, and |
7 |
> > there is no confusion about them. Adding a plain qt flag in there |
8 |
> > brings back the gtk/gtk2 mess that we've presumably been trying to |
9 |
> > avoid in the future. |
10 |
> |
11 |
> That depends on how it's done. If it's done in a simple and obvious |
12 |
> way (USE=qt means use the best available qt, USE=qt# for other weird |
13 |
|
14 |
where "available" means "available in the tree for arch", not |
15 |
"already installed on build system" (just to be clear - correct me if |
16 |
I'm wrong) |
17 |
|
18 |
> stuff that most people don't care about and so can ignore), it |
19 |
> shouldn't be that bad. |
20 |
|
21 |
So are you suggesting something like: |
22 |
|
23 |
qt - Add support for QT/include QT GUI |
24 |
qt3 - build for version 3 of QT |
25 |
|
26 |
where dependencies might be something like: |
27 |
|
28 |
qt? ( qt3? ( >=dev-libs/qt-3.3.6 |
29 |
<dev-libs/qt-4 ) |
30 |
!qt3? ( >= dev-libs/qt-4.1 ) ) |
31 |
|
32 |
for a package that can build against either qt3 (3.3.6 or higher) or |
33 |
qt4 (4.1 or higher) but not both simultaneously, and perhaps: |
34 |
|
35 |
qt? ( >= dev-libs/qt-4.1 |
36 |
qt3? ( >=dev-libs/qt-3.3.6 |
37 |
<dev-libs/qt-4 ) ) |
38 |
|
39 |
for packages that can build simultaneously for both (is this situation |
40 |
realistic?). We'd need a qt4 to get just the qt3 package in that case: |
41 |
|
42 |
qt? ( qt4? ( >= dev-libs/qt-4.1 ) |
43 |
qt3? ( >=dev-libs/qt-3.3.6 |
44 |
<dev-libs/qt-4 ) ) |
45 |
|
46 |
Am I making sense? This looks a lot like the gtk/gtk2 flags, but |
47 |
inverted; according to use.desc, gtk builds gtk+-1 unless gtk2 is set, |
48 |
whereas the above builds highest version compatible with the |
49 |
package unless a lower version is specifically requested through USE. |
50 |
|
51 |
Ideally we should be consistent in handling this issue (which |
52 |
presumably isn't limited to just gtk and qt), although it may not be |
53 |
worth the disruption to rework gtk/gtk2 into gtk/gtk1. |
54 |
|
55 |
-- |
56 |
Kevin F. Quinn |