| 1 |
On Sat, Sep 12, 2015 at 12:55 AM, Raymond Jennings <shentino@×××××.com> wrote: |
| 2 |
> On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman <rich0@g.o> wrote: |
| 3 |
>> |
| 4 |
>> On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell <zlg@g.o> wrote: |
| 5 |
>> > |
| 6 |
>> > I like the general 'gtk' flag we generally use to choose *which* |
| 7 |
>> > toolkit, and local USE flags for specific versions, if they are |
| 8 |
>> > supported. But in that case, the general gtk flag should be |
| 9 |
>> > interpreted as the latest version supported, so users don't come |
| 10 |
>> > across weirdly behaving packages that default to gtk2 (unless that |
| 11 |
>> > version is the most stable). |
| 12 |
>> > |
| 13 |
>> >... |
| 14 |
>> > |
| 15 |
>> > For starters, versioned USE flags more than likely don't belong in |
| 16 |
>> > make.conf's USE variable and shouldn't be global. |
| 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 |
He wasn't suggesting that they have different meanings for different |
| 25 |
packages. By saying that they shouldn't be global he meant that users |
| 26 |
should not typically be manipulating them at a global level, such as |
| 27 |
in make.conf. |
| 28 |
|
| 29 |
Back in the day it was common to stick flags like these in make.conf |
| 30 |
or in profiles, since if you didn't packages wouldn't build GUIs and |
| 31 |
such. That was before USE defaults and it caused a lot of headaches |
| 32 |
when multiple versions of toolkits started coming along and setting |
| 33 |
these flags started causing harm. |
| 34 |
|
| 35 |
But, the way we use the terms local/global USE flags is confusing. |
| 36 |
They can mean that a flag has a package-specific vs global meaning, or |
| 37 |
the terms can mean that it is recommended that the flag be enabled at |
| 38 |
the package.use level vs at the make.conf level. To be fair to you, |
| 39 |
until very recently the first meaning was the most common. People are |
| 40 |
talking more about the second meaning of late because of problems that |
| 41 |
happen when people try to tweak fairly detailed settings like gtk3 at |
| 42 |
the global level. |
| 43 |
|
| 44 |
> |
| 45 |
>> I'd be tempted to even say to not have gtk3 but instead call the flag |
| 46 |
>> chromium-gtk3 or whatever so that it becomes very difficult to put in |
| 47 |
>> the global config. However, that goes against our general principle |
| 48 |
>> of letting the user break their system and keep the pieces if they |
| 49 |
>> think they know what they're doing. If somebody WANTS to test out a |
| 50 |
>> gtk3-only system or whatever they should have the freedom to do so, |
| 51 |
>> understanding that testing sometimes uncovers problems. |
| 52 |
> |
| 53 |
> I actually also think that there should be a single USE flag for building on |
| 54 |
> gtk3, called gtk3. calling it "(packagename)-gtk3" is a bit redundant, and |
| 55 |
> also flies in the face of having a single global flag with a coherent |
| 56 |
> purpose. |
| 57 |
> |
| 58 |
|
| 59 |
The only reason for doing it the other way would be to make it harder |
| 60 |
for users to shoot themselves in the foot by setting these flags in |
| 61 |
make.conf. They'd have to put 50 flags in make.conf and not just one. |
| 62 |
However, in general Gentoo operates under the principle that while we |
| 63 |
should avoid surprising the user, we shouldn't actually make it hard |
| 64 |
for the user to override our decisions when they feel it is best. |
| 65 |
|
| 66 |
-- |
| 67 |
Rich |
Archives