| 1 |
On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman <rich0@g.o> wrote: |
| 2 |
|
| 3 |
> On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell <zlg@g.o> wrote: |
| 4 |
> > |
| 5 |
> > I like the general 'gtk' flag we generally use to choose *which* |
| 6 |
> > toolkit, and local USE flags for specific versions, if they are |
| 7 |
> > supported. But in that case, the general gtk flag should be |
| 8 |
> > interpreted as the latest version supported, so users don't come |
| 9 |
> > across weirdly behaving packages that default to gtk2 (unless that |
| 10 |
> > version is the most stable). |
| 11 |
> > |
| 12 |
> >... |
| 13 |
> > |
| 14 |
> > For starters, versioned USE flags more than likely don't belong in |
| 15 |
> > make.conf's USE variable and shouldn't be global. |
| 16 |
> |
| 17 |
|
| 18 |
Personally i disagree with this. |
| 19 |
|
| 20 |
Versioned use flags for widely used dependencies (like a windowing toolkit) |
| 21 |
IMO qualify as global USE flags because they have a common effect across |
| 22 |
many packages. |
| 23 |
|
| 24 |
That was roughly my proposal. |
| 25 |
> |
| 26 |
> USE=gui or something like that if the main effect is to have a gui or |
| 27 |
> not. That is the sort of thing that SHOULD go in make.conf or in a |
| 28 |
> profile. If disabling gtk makes it a console-only application then |
| 29 |
> use the gui flag. |
| 30 |
> |
| 31 |
> USE=gtk if the main effect is to select /which/ toolkit is used if |
| 32 |
> more than one is optionally supported. That /might/ go in a make.conf |
| 33 |
> or profile, but probably shouldn't in general. It is more appropriate |
| 34 |
> for something like the desktop/gnome profile than the desktop profile. |
| 35 |
> |
| 36 |
> USE=gtk# if you're picking which version to use. That should /almost |
| 37 |
> never/ go in a profile (unless you're talking about a testing profile |
| 38 |
> of some kind, such as on an overlay), or in a global config unless you |
| 39 |
> REALLY know what you're getting into. Users setting this globally |
| 40 |
> should expect to run into bugs. The package should default these |
| 41 |
> flags to whatever is most appropriate for the specific package. |
| 42 |
> |
| 43 |
|
| 44 |
I really like this approach, and I think that having tiers of |
| 45 |
(gui)->(qt/gtk)->(qt4/qt5//gtk2/gtk3) would go a long way to keeping USE |
| 46 |
flags coherent. |
| 47 |
|
| 48 |
I'd be tempted to even say to not have gtk3 but instead call the flag |
| 49 |
> chromium-gtk3 or whatever so that it becomes very difficult to put in |
| 50 |
> the global config. However, that goes against our general principle |
| 51 |
> of letting the user break their system and keep the pieces if they |
| 52 |
> think they know what they're doing. If somebody WANTS to test out a |
| 53 |
> gtk3-only system or whatever they should have the freedom to do so, |
| 54 |
> understanding that testing sometimes uncovers problems. |
| 55 |
> |
| 56 |
|
| 57 |
I actually also think that there should be a single USE flag for building |
| 58 |
on gtk3, called gtk3. calling it "(packagename)-gtk3" is a bit redundant, |
| 59 |
and also flies in the face of having a single global flag with a coherent |
| 60 |
purpose. |
| 61 |
|
| 62 |
Of course any change will need a transition period, news, handbook |
| 63 |
> updates, etc. For the person who wants the "just works" experience |
| 64 |
> they can pick a profile and it will do the right thing, and if they |
| 65 |
> want to tailor things a bit more the USE=(-)gui flag will do what it |
| 66 |
> would be expected to do. |
| 67 |
> |
| 68 |
> -- |
| 69 |
> Rich |
| 70 |
> |
| 71 |
> |
Archives