Re: [gentoo-dev] [RFC] Global USE=gui

[Ulrich Mueller]

> On Fri, 10 Jun 2016, Ciaran McCreesh wrote:

> On Fri, 10 Jun 2016 00:18:44 +0200
> Ulrich Mueller  wrote:
>> > On Thu, 9 Jun 2016, Michał Górny wrote:  
>> > Who did establish that *idiotic* policy and why is he still a
>> > developer?  
>> 
>> Michał,
>> You may want to reconsider your tone.
>> 
>> The policy was established when documenting REQUIRED_USE for EAPI 4,
>> and it is based on consensus in bug 353624 [1] and in the gentoo-dev
>> mailing list [2,3].

> Really, that policy predates REQUIRED_USE, and even EAPIs... In the
> olden days, the rule was that USE flags were for things that were
> optional, and that if something wasn't optional, then it shouldn't
> be controlled by USE flags.

You are right, the word "established" above isn't accurate. Rather,
the existing policy was confirmed after introduction of REQUIRED_USE.

Ulrich


pgpCZFFzDP4M9.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Ciaran McCreesh]

On Fri, 10 Jun 2016 00:18:44 +0200
Ulrich Mueller  wrote:
> > On Thu, 9 Jun 2016, Michał Górny wrote:  
> >> That would be a policy violation. Packages should pick a reasonable
> >> default if flags are conflicting, but not force users to
> >> micro-manage their flags.  
> 
> > Who did establish that *idiotic* policy and why is he still a
> > developer?  
> 
> Michał,
> You may want to reconsider your tone.
> 
> The policy was established when documenting REQUIRED_USE for EAPI 4,
> and it is based on consensus in bug 353624 [1] and in the gentoo-dev
> mailing list [2,3].

Really, that policy predates REQUIRED_USE, and even EAPIs... In the
olden days, the rule was that USE flags were for things that were
optional, and that if something wasn't optional, then it shouldn't be
controlled by USE flags.

-- 
Ciaran McCreesh

Re: [gentoo-dev] [RFC] Global USE=gui

[Ulrich Mueller]

> On Thu, 9 Jun 2016, Michał Górny wrote:

>> That would be a policy violation. Packages should pick a reasonable
>> default if flags are conflicting, but not force users to
>> micro-manage their flags.

> Who did establish that *idiotic* policy and why is he still a
> developer?

Michał,
You may want to reconsider your tone.

The policy was established when documenting REQUIRED_USE for EAPI 4,
and it is based on consensus in bug 353624 [1] and in the gentoo-dev
mailing list [2,3].

Ulrich


[1] https://bugs.gentoo.org/show_bug.cgi?id=353624#c6
[2] http://thread.gmane.org/gmane.linux.gentoo.devel/69755/focus=69772
[3] http://thread.gmane.org/gmane.linux.gentoo.devel/69755/focus=69776


pgp6uX4iHcYK6.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:



2. Packages use REQUIRED_USE to force an appropriate choice.


That would be a policy violation. Packages should pick a reasonable
default if flags are conflicting, but not force users to micro-manage
their flags.


Who did establish that *idiotic* policy and why is he still
a developer? The whole *point of USE Flags* is to let people
micro-manage stuff. Picking up a random default makes flags
meaningless, confusing and makes it impossible to establish
appropriate USE dependencies.


I assume "micro-manage" means users maintaining extensive lists of 
per-package flags in package.use, which I agree with ulm is to be avoided.


Setting the USE flags once in make.conf would not qualify as micro-managing 
in my opinion.


There is an exception though, in cases where this breaks reverse USE 
dependencies, it may be allowed and necessary to use REQUIRED_USE[0].



Best regards,
Chí-Thanh Christopher Nguyễn

[0] 
https://devmanual.gentoo.org/general-concepts/use-flags/index.html#conflicting-use-flags




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Michał Górny]

On Thu, 9 Jun 2016 22:24:20 +0200
Ulrich Mueller  wrote:

> > On Thu, 9 Jun 2016, Michał Górny wrote:  
> 
> > That said, I think we could go with some generic idea like this
> > (assumes new GUI expand is being used):  
> 
> > [...]  
> 
> > 2. Packages use REQUIRED_USE to force an appropriate choice.  
> 
> That would be a policy violation. Packages should pick a reasonable
> default if flags are conflicting, but not force users to micro-manage
> their flags.

Who did establish that *idiotic* policy and why is he still
a developer? The whole *point of USE Flags* is to let people
micro-manage stuff. Picking up a random default makes flags
meaningless, confusing and makes it impossible to establish
appropriate USE dependencies.

-- 
Best regards,
Michał Górny



pgp4ajVRrfpAZ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Ulrich Mueller]

> On Thu, 9 Jun 2016, Michał Górny wrote:

> That said, I think we could go with some generic idea like this
> (assumes new GUI expand is being used):

> [...]

> 2. Packages use REQUIRED_USE to force an appropriate choice.

That would be a policy violation. Packages should pick a reasonable
default if flags are conflicting, but not force users to micro-manage
their flags.

Ulrich


pgpjoGPHAeN8Z.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Michał Górny]

On Tue, 7 Jun 2016 12:03:16 -0700
Brian Dolbec  wrote:

> We instead implement something along the lines of:
> 
> an ordered list of the gui toolkits in their preferred order of
> desirability.  This should be an all inclusive list.  Note: these are
> subject to package.use setting overrides.
> 
> PREFERRED_GUIS="gtk2 qt4 qt5 x wxwidgets X ... ncurses tty -gkt3"
> 
> In the above it means that if gtk2 is an option, then choose it, mask
> (de-select) the others.
> In there it also means DO NOT SELECT gtk3  So if you want a pkg and
> it NEEDS gtk3, then the PM will puke it back at you saying you can't
> have one without the other...
> So, then you have to fix it manually via package.use settings.  Accept
> gtk3 for this pkg only (not that it doesn't likely have other gtk3
> deps that will also need this...)
> 
> In the general case it will pick the first toolkit in order of
> preference (left to right) and only that toolkit that the pkg is capable
> of using.
> 
> For pkgs capable of multiple simultaneous toolkits installed, then
> again, manual intervention would be needed to set package.use.
> 
> This would also have to be a package manager feature and run similar to
> the auto-unmask feature.
> 
> FEATURES="preferred-guis"
> 
> Let's try and keep things as simple as possible.
> From what I've gleaned form the emails I have read, is that what the
> general user wants to happen, select the toolkit in the order of their
> preference.

Could we please try to stay generic and not invent specific ugly hacks
for specific hardcoded flag names? We're trying hard to kill those
things, and I'd really feel bad if Portage got more of them.


That said, I think we could go with some generic idea like this
(assumes new GUI expand is being used):

1. Packages use IUSE defaults to set the preferred GUI:

  IUSE="gui_gtk2 +gui_gtk3 ..."

2. Packages use REQUIRED_USE to force an appropriate choice.

3. The default is GUI="", and users who don't care get the choice taken
by IUSE defaults.

4. For those who care, we implement one of the two mechanisms. Either:

a. flag preference lists -- i.e. something like '|| ( gtk3 gtk2 ... )'
in package.use,

b. or flag 'toggling' notes -- like 'gtk3 -gtk2~ -qt5~~ ...'.

Both solutions provide directions for the PM in case REQUIRED_USE
constraints fail.


I think the preference lists are more obvious. For example:

  */* GUI: || ( gtk3 gtk2 )

would mean that by default GUI=gtk3. However, if a package fails to
meet REQUIRED_USE, it is retried with GUI=gtk2. If that one fails as
well, user is asked to take action.

The main problem I see with this, is how to combine multiple
package.use entries (i.e. the global flags with local flags).


The 'toggling' notes are a little more complex. Basically, the idea is
that '~' indicator means that the flag can be toggled in order to
attempt to solve REQUIRED_USE. The more '~'s, the less preferred
toggling is. For example:

  */* GUI: gtk3 qt5~ -gtk2~~

means that:

a) gtk3 is always ON, and can't be toggled (however, it may not be
in IUSE),

b) qt5 is ON by default but can be toggled off if REQUIRED_USE conflict
occurs,

c) gtk2 is OFF by default but can be toggled on (as second attempt) if
REQUIRED_USE fails.

Basically the idea is that PM tries the default set first, then
attempts to toggle flags with '~', then with '~~', then possibly '~' +
'~~'...

In this case, the idea would be that the user prefers having both gtk3
and qt5. But if that's impossible, he prefers gtk3 only. if that's
impossible, PM should try 'gtk3 qt5 gtk2', then 'gtk3 gtk2'... And if
all '~'s don't help, REQUIRED_USE is left for user invention.

-- 
Best regards,
Michał Górny



pgp6_zPgu1PxE.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Michał Górny]

On Tue, 7 Jun 2016 17:31:49 -0400
Michael Orlitzky  wrote:

> On 06/07/2016 04:59 PM, Michał Górny wrote:
> >>
> >> I'll believe this when I see it =P  
> > 
> > You won't because the Gentoo way is to create a shitload of hacks
> > instead of fixing the root issue.
> >   
> 
> I'm not arguing for anything here, I'm just toying around with an idea
> for fun. What we want is a way to declare USE flag constraints within an
> ebuild that,
> 
>   1) Runs quickly
>   2) Prevents a package from being installed with conflicting flags
>   3) Preferably has a simple grammar and doesn't require bash
>   4) Outputs a sensible message to the user upon conflict
> 
> The error message is the one clear point that pkg_pretend holds over
> REQUIRED_USE. If we can make portage do something sensible when it hits
> a REQUIRED_USE conflict, that would be ideal. But aren't (2) and (4) the
> most important points?
> 
> 
> >>
> >> So 7 minutes for an understandable English description of the error and
> >> how to fix it, versus 5 minutes for line noise? There's a great story in
> >> The Psychology of Computer Programming that ends like this:  
> > 
> > Not 5 minutes. Depending on the context, Portage can complain about
> > REQUIRED_USE in a few seconds because it has no further point
> > in evaluating the depgraph.
> >   
> 
> It doesn't do this, does it? I think it waits until the end. It *could*
> run pkg_pretend earlier, too, but it doesn't.
> 
> 
> >   
> >>> 3. REQUIRED_USE can take USE dependencies into account. pkg_pretend()
> >>> can't.
> >>
> >> What do you mean here?  
> > 
> > I mean that if A depends on B[gtk2], and you have ^^ ( gtk2 gtk3 ),
> > Portage will clearly know gtk2 is the only solution. Your pkg_pretend()
> > will tell user to enable gtk3, then Portage will hit unsolvable deps.
> > Congratulations, your helpful output just resulted in even worse
> > output!
> >   
> 
> gtk2 is not the only solution: I could set B[gtk2] and A[gtk3] in
> package.use. (If gtk2 *were* the only solution, then why would you have
> the REQUIRED_USE in the first place? Just pass --with-gtk2.)
> 
> In practice, I would set A[gtk3] in package.use, and then try to emerge
> it again. Portage would tell me that I needed to set B[gtk2] first, and
> I would do that and start over.
> 
> 
> >> See #2, but "each package" is an overestimate. Only the ones with a
> >> non-trivial pkg_pretend() phase would take any time.  
> > 
> > Have you tried it, or is it wild guess? What I'm saying is that
> > *pkg_pretend implementation in Portage is TERRIBLY SLOW*. Even
> > a complete no-op takes a lot of time because Portage needs to do a lot
> > of setup to run it, and can't do multiple packages in parallel.
> >   
> 
> Of course I haven't tried it =)
> 
> One of two scenarios holds, though:
> 
>  * if a trivial pkg_pretend() is slow, then one that checks for USE
>flag conflicts isn't actually that much slower.
> 
>  * if a trivial pkg_pretend() is fast, then only those packages that
>have a non-trivial pkg_pretend() make it slower.
> 
> REQUIRED_USE should be faster either way, but that's currently at the
> expense of the error messages and I'm not sure those *can* be fixed.

To summarize your point: bad solution is good because it's not much
worse than itself.

-- 
Best regards,
Michał Górny



pgpUFmAYunx0Y.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Rich Freeman]

On Tue, Jun 7, 2016 at 3:03 PM, Brian Dolbec  wrote:
>
> an ordered list of the gui toolkits in their preferred order of
> desirability.  This should be an all inclusive list.  Note: these are
> subject to package.use setting overrides.
>

This has been my thought as well.  This really isn't limited to
graphics toolkits either.  It probably requires PMS support to do
well, though maybe we could get away with an eclass of some kind (but
messing with USE and dependencies dynamically seems problematic in an
eclass).

Let's take a USE_EXPAND-like ordered list of flags:  A="a c d e"

A package could support exactly one or any number of these flags.  A
package could require one or none of these flags.  The package would
somehow express whether it handles only one and whether it requires
any.  This might be done by calling a function and passing the list of
supported flags and A.

Then portage would expand this into a list of USE flags that get
applied.  If only one is supported then the effective USE flag will be
the first flag in the list that the package supports.  If it supports
more than one then the effective flags would include all the flags the
package supports which are in the list.  If the package requires a
flag then if in the end no flags intersected then portage will die
with an error.

>From that point the flags work like ordinary USE flags - they get
added to USE and can be used to pull in dependencies or turn on
features.  Since they've been pre-filtered down to one or many and
requirements were dealt with you generally don't need rat-nests of
conditionals to deal with these situations all over the place.

I can still see some issues here.  Maybe a package can support up to
one qt option and up to one gtk option.  Maybe the list of supported
flags won't be "qt4 qt5 gtk2 gtk3" but rather something like " ( qt4
qt5 ) ( gtk2 gtk3 ) " or some other syntax that expresses the same
sort of thing.

The goal should be to make this more declarative and less procedural,
which is the general trend here.

-- 
Rich

Re: [gentoo-dev] [RFC] Global USE=gui

[David Seifert]

On Di, 2016-06-07 at 12:03 -0700, Brian Dolbec wrote:
> On Tue, 7 Jun 2016 14:29:58 -0400
> Michael Orlitzky  wrote:
> 
> > 
> > On 06/07/2016 12:20 PM, Michał Górny wrote:
> > > 
> > > 
> > > So many weird ideas... while the simplest one is a proper
> > > REQUIRED_USE with gui being the control flag, and IUSE defaults
> > > to
> > > select the preferred toolkit.
> > >   
> > This is what came to my mind.
> > 
> > The underlying problem that we are hitting (a la Patrick) is that
> > USE
> > flags are supposed to be a user-interface for building software
> > from
> > source, but implementation details are an important part of
> > configuring the software to be built.
> > 
> > It would be nice if USE=gui meant "build a GUI" and that was all
> > the
> > input that we needed from the user. But if the upstream package
> > supports both QT and GTK and we need to pass either --with-qt or
> > --with-gtk to the build system, then there is an unavoidable choice
> > to be made. We can prefer one, but both options need to be
> > available.
> > 
> > If we want the best of both worlds -- a nice user-interface and
> > full
> > configurability -- then we can use "the user wants a GUI" as a
> > trigger
> > for the implementation choice. If there's a default implementation
> > and
> > the user doesn't care, no further interference should be necessary.
> > Otherwise the presence of the generic USE=gui will let us know, so
> > we
> > can let the user know, that he needs to pick one.
> > 
> > 
> This is where my thought from a few days ago kicks in...
> I had started to discuss it with Kristian.
> 
> 
> I propose to help alleviate the __MESS__ from all this force-foo and
> other complicated USE flag REQUIRED_USE madness...
> 
> We instead implement something along the lines of:
> 
> an ordered list of the gui toolkits in their preferred order of
> desirability.  This should be an all inclusive list.  Note: these are
> subject to package.use setting overrides.
> 
> PREFERRED_GUIS="gtk2 qt4 qt5 x wxwidgets X ... ncurses tty -gkt3"
> 
> In the above it means that if gtk2 is an option, then choose it, mask
> (de-select) the others.
> In there it also means DO NOT SELECT gtk3  So if you want a pkg
> and
> it NEEDS gtk3, then the PM will puke it back at you saying you can't
> have one without the other...
> So, then you have to fix it manually via package.use
> settings.  Accept
> gtk3 for this pkg only (not that it doesn't likely have other gtk3
> deps that will also need this...)
> 
> In the general case it will pick the first toolkit in order of
> preference (left to right) and only that toolkit that the pkg is
> capable
> of using.
> 
> For pkgs capable of multiple simultaneous toolkits installed, then
> again, manual intervention would be needed to set package.use.
> 
> This would also have to be a package manager feature and run similar
> to
> the auto-unmask feature.
> 
> FEATURES="preferred-guis"
> 
> Let's try and keep things as simple as possible.
> From what I've gleaned form the emails I have read, is that what the
> general user wants to happen, select the toolkit in the order of
> their
> preference.
+1

Personally I see this as the only tractable option to stop the
insanity.

David

Re: [gentoo-dev] [RFC] Global USE=gui

[Michael Orlitzky]

On 06/07/2016 04:59 PM, Michał Górny wrote:
>>
>> I'll believe this when I see it =P
> 
> You won't because the Gentoo way is to create a shitload of hacks
> instead of fixing the root issue.
> 

I'm not arguing for anything here, I'm just toying around with an idea
for fun. What we want is a way to declare USE flag constraints within an
ebuild that,

  1) Runs quickly
  2) Prevents a package from being installed with conflicting flags
  3) Preferably has a simple grammar and doesn't require bash
  4) Outputs a sensible message to the user upon conflict

The error message is the one clear point that pkg_pretend holds over
REQUIRED_USE. If we can make portage do something sensible when it hits
a REQUIRED_USE conflict, that would be ideal. But aren't (2) and (4) the
most important points?


>>
>> So 7 minutes for an understandable English description of the error and
>> how to fix it, versus 5 minutes for line noise? There's a great story in
>> The Psychology of Computer Programming that ends like this:
> 
> Not 5 minutes. Depending on the context, Portage can complain about
> REQUIRED_USE in a few seconds because it has no further point
> in evaluating the depgraph.
> 

It doesn't do this, does it? I think it waits until the end. It *could*
run pkg_pretend earlier, too, but it doesn't.


> 
>>> 3. REQUIRED_USE can take USE dependencies into account. pkg_pretend()
>>> can't.  
>>
>> What do you mean here?
> 
> I mean that if A depends on B[gtk2], and you have ^^ ( gtk2 gtk3 ),
> Portage will clearly know gtk2 is the only solution. Your pkg_pretend()
> will tell user to enable gtk3, then Portage will hit unsolvable deps.
> Congratulations, your helpful output just resulted in even worse
> output!
> 

gtk2 is not the only solution: I could set B[gtk2] and A[gtk3] in
package.use. (If gtk2 *were* the only solution, then why would you have
the REQUIRED_USE in the first place? Just pass --with-gtk2.)

In practice, I would set A[gtk3] in package.use, and then try to emerge
it again. Portage would tell me that I needed to set B[gtk2] first, and
I would do that and start over.


>> See #2, but "each package" is an overestimate. Only the ones with a
>> non-trivial pkg_pretend() phase would take any time.
> 
> Have you tried it, or is it wild guess? What I'm saying is that
> *pkg_pretend implementation in Portage is TERRIBLY SLOW*. Even
> a complete no-op takes a lot of time because Portage needs to do a lot
> of setup to run it, and can't do multiple packages in parallel.
> 

Of course I haven't tried it =)

One of two scenarios holds, though:

 * if a trivial pkg_pretend() is slow, then one that checks for USE
   flag conflicts isn't actually that much slower.

 * if a trivial pkg_pretend() is fast, then only those packages that
   have a non-trivial pkg_pretend() make it slower.

REQUIRED_USE should be faster either way, but that's currently at the
expense of the error messages and I'm not sure those *can* be fixed.

Re: [gentoo-dev] [RFC] Global USE=gui

[Ciaran McCreesh]

On Tue, 7 Jun 2016 22:59:42 +0200
Michał Górny  wrote:
> Not 5 minutes. Depending on the context, Portage can complain about
> REQUIRED_USE in a few seconds because it has no further point
> in evaluating the depgraph.

...but it shouldn't, because then it only gives you the first error.

-- 
Ciaran McCreesh

Re: [gentoo-dev] [RFC] Global USE=gui

[Michał Górny]

On Tue, 7 Jun 2016 16:31:52 -0400
Michael Orlitzky  wrote:

> On 06/07/2016 02:57 PM, Michał Górny wrote:
> > 
> > The point is that:
> > 
> > 1. REQUIRED_USE is semi-machine-understandable while pkg_pretend() is
> > some random function crap.  
> 
> Why do users care about that? Why do I even care about that? The whole
> ebuild is random function crap. The only benefit is consistent output,
> but it's consistently awful.
> 
> 
> > Portage can be improved to take some sensible action on it.   
> 
> I'll believe this when I see it =P

You won't because the Gentoo way is to create a shitload of hacks
instead of fixing the root issue.

> > 2. REQUIRED_USE can be handled early during dependency resolution.
> > pkg_pretend() is like I want 5 minutes for Portage to calculate
> > the dependencies, then 2 minutes to run pkg_pretend()s, then it tells
> > me I am supposed to change one thing and start over.  
> 
> So 7 minutes for an understandable English description of the error and
> how to fix it, versus 5 minutes for line noise? There's a great story in
> The Psychology of Computer Programming that ends like this:

Not 5 minutes. Depending on the context, Portage can complain about
REQUIRED_USE in a few seconds because it has no further point
in evaluating the depgraph.

Versus wasting a lot of time on a huge depgraph that will be never used
because although it seems to be correct, it isn't and pkg_pretend() is
used to tell 'you did all the work for nothing'. Back to EAPI 0, eh?

> > 3. REQUIRED_USE can take USE dependencies into account. pkg_pretend()
> > can't.  
> 
> What do you mean here?

I mean that if A depends on B[gtk2], and you have ^^ ( gtk2 gtk3 ),
Portage will clearly know gtk2 is the only solution. Your pkg_pretend()
will tell user to enable gtk3, then Portage will hit unsolvable deps.
Congratulations, your helpful output just resulted in even worse
output!

> > 4. pkg_pretend() is slow, and should be used scarcely. Adding
> > an additional slow step for each package on the list, before starting to
> > build packages is not really helpful.
> >   
> 
> See #2, but "each package" is an overestimate. Only the ones with a
> non-trivial pkg_pretend() phase would take any time.

Have you tried it, or is it wild guess? What I'm saying is that
*pkg_pretend implementation in Portage is TERRIBLY SLOW*. Even
a complete no-op takes a lot of time because Portage needs to do a lot
of setup to run it, and can't do multiple packages in parallel.

-- 
Best regards,
Michał Górny



pgpSWkIbtwo2j.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Michael Orlitzky]

On 06/07/2016 02:57 PM, Michał Górny wrote:
> 
> The point is that:
> 
> 1. REQUIRED_USE is semi-machine-understandable while pkg_pretend() is
> some random function crap.

Why do users care about that? Why do I even care about that? The whole
ebuild is random function crap. The only benefit is consistent output,
but it's consistently awful.


> Portage can be improved to take some sensible action on it. 

I'll believe this when I see it =P


> 2. REQUIRED_USE can be handled early during dependency resolution.
> pkg_pretend() is like I want 5 minutes for Portage to calculate
> the dependencies, then 2 minutes to run pkg_pretend()s, then it tells
> me I am supposed to change one thing and start over.

So 7 minutes for an understandable English description of the error and
how to fix it, versus 5 minutes for line noise? There's a great story in
The Psychology of Computer Programming that ends like this:

  "And how long does your program take?" he asked--emphasizing the
  possessive.

  "That varies with the input," was the reply, "but on average, about
  ten seconds per card."

  "Aha," was the triumphant reply. "But my program takes only one
  second per card."

  The members of the audience--who had, after all, all contributed to
  the one-second version--seemed relieved. But our hero, who was rather
  young and naive, was not put down by this remark. Instead, he calmly
  observed, "But your program doesn't work. If the program doesn't have
  to work, I can write one that takes one millisecond per card--and
  that's faster than our card reader."


> 
> 3. REQUIRED_USE can take USE dependencies into account. pkg_pretend()
> can't.

What do you mean here?


> 4. pkg_pretend() is slow, and should be used scarcely. Adding
> an additional slow step for each package on the list, before starting to
> build packages is not really helpful.
> 

See #2, but "each package" is an overestimate. Only the ones with a
non-trivial pkg_pretend() phase would take any time.

Re: [gentoo-dev] [RFC] Global USE=gui

[Brian Dolbec]

On Tue, 7 Jun 2016 14:29:58 -0400
Michael Orlitzky  wrote:

> On 06/07/2016 12:20 PM, Michał Górny wrote:
> > 
> > So many weird ideas... while the simplest one is a proper
> > REQUIRED_USE with gui being the control flag, and IUSE defaults to
> > select the preferred toolkit.
> >   
> 
> This is what came to my mind.
> 
> The underlying problem that we are hitting (a la Patrick) is that USE
> flags are supposed to be a user-interface for building software from
> source, but implementation details are an important part of
> configuring the software to be built.
> 
> It would be nice if USE=gui meant "build a GUI" and that was all the
> input that we needed from the user. But if the upstream package
> supports both QT and GTK and we need to pass either --with-qt or
> --with-gtk to the build system, then there is an unavoidable choice
> to be made. We can prefer one, but both options need to be available.
> 
> If we want the best of both worlds -- a nice user-interface and full
> configurability -- then we can use "the user wants a GUI" as a trigger
> for the implementation choice. If there's a default implementation and
> the user doesn't care, no further interference should be necessary.
> Otherwise the presence of the generic USE=gui will let us know, so we
> can let the user know, that he needs to pick one.
> 
> 

This is where my thought from a few days ago kicks in...
I had started to discuss it with Kristian.


I propose to help alleviate the __MESS__ from all this force-foo and
other complicated USE flag REQUIRED_USE madness...

We instead implement something along the lines of:

an ordered list of the gui toolkits in their preferred order of
desirability.  This should be an all inclusive list.  Note: these are
subject to package.use setting overrides.

PREFERRED_GUIS="gtk2 qt4 qt5 x wxwidgets X ... ncurses tty -gkt3"

In the above it means that if gtk2 is an option, then choose it, mask
(de-select) the others.
In there it also means DO NOT SELECT gtk3  So if you want a pkg and
it NEEDS gtk3, then the PM will puke it back at you saying you can't
have one without the other...
So, then you have to fix it manually via package.use settings.  Accept
gtk3 for this pkg only (not that it doesn't likely have other gtk3
deps that will also need this...)

In the general case it will pick the first toolkit in order of
preference (left to right) and only that toolkit that the pkg is capable
of using.

For pkgs capable of multiple simultaneous toolkits installed, then
again, manual intervention would be needed to set package.use.

This would also have to be a package manager feature and run similar to
the auto-unmask feature.

FEATURES="preferred-guis"

Let's try and keep things as simple as possible.
From what I've gleaned form the emails I have read, is that what the
general user wants to happen, select the toolkit in the order of their
preference.
-- 
Brian Dolbec 

Re: [gentoo-dev] [RFC] Global USE=gui

[Michał Górny]

On Tue, 7 Jun 2016 14:50:36 -0400
Michael Orlitzky  wrote:

> On 06/07/2016 12:20 PM, Michał Górny wrote:
> >>
> >> A pkg_pretend() message would certainly make sense and IMO be a good
> >> idea, but again this isn't any different than the situation as it
> >> stands now WITHOUT a USE=gui.  Regardless I don't see this as a
> >> blocker to the idea.  
> > 
> > Nope, it won't. It will only make things slower, more clumsy
> > and provide no real benefit. pkg_pretend() should be reserved for
> > checks really needed to build packages and not abused to do some early
> > output.
> >   
> 
> I forgot to reply to this.
> 
> The benefit of pkg_pretend is that it lets you give a sensible error
> message. This is not a complex problem we're asking the user to resolve.
> Here's what the error would say if I used pkg_pretend:
> 
>   This package supports two different toolkits, gtk2 and gtk3. Please
>   choose one and add it to your USE flags for .
> 
> Here's what it says with REQUIRED_USE:
> 
>   !!! Problem resolving dependencies for x11-drivers/nvidia-drivers
>   from @selected
>   ... done!
> 
>   !!! The ebuild selected to satisfy "x11-drivers/nvidia-drivers" has
>   unmet requirements.
>   - x11-drivers/nvidia-drivers-352.30::gentoo USE="X multilib tools
>   -acpi -gtk2 -gtk3 -pax_kernel -uvm" ABI_X86="64"
> 
>   The following REQUIRED_USE flag constraints are unsatisfied:
> tools? ( any-of ( gtk2 gtk3 ) )
> 
>   The above constraints are a subset of the following complete
>   expression:
> tools? ( X any-of ( gtk2 gtk3 ) )
> 
> We could make the portage output a little better, but that's going to be
> an uphill battle and still won't be as informative or short as the
> pkg_pretend version.
> 
> What we really need is a way to tie an error message to a REQUIRED_USE
> clause. I think I remember Ciaran sarcastically suggesting that we make
> REQUIRED_USE a dictionary lookup from clause => message. The sarcasm was
> probably because all we'd be doing is replacing the if/then/die
> statements (that we'd use in pkg_pretend) with ?,(), and => in
> REQUIRED_USE. It's an abstraction without any benefit at that point.

The point is that:

1. REQUIRED_USE is semi-machine-understandable while pkg_pretend() is
some random function crap. Portage can be improved to take some
sensible action on it. With pkg_pretend, we can't do anything but print.

2. REQUIRED_USE can be handled early during dependency resolution.
pkg_pretend() is like I want 5 minutes for Portage to calculate
the dependencies, then 2 minutes to run pkg_pretend()s, then it tells
me I am supposed to change one thing and start over.

3. REQUIRED_USE can take USE dependencies into account. pkg_pretend()
can't.

4. pkg_pretend() is slow, and should be used scarcely. Adding
an additional slow step for each package on the list, before starting to
build packages is not really helpful.

-- 
Best regards,
Michał Górny



pgpwx35ii79pB.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Michael Orlitzky]

On 06/07/2016 12:20 PM, Michał Górny wrote:
>>
>> A pkg_pretend() message would certainly make sense and IMO be a good
>> idea, but again this isn't any different than the situation as it
>> stands now WITHOUT a USE=gui.  Regardless I don't see this as a
>> blocker to the idea.
> 
> Nope, it won't. It will only make things slower, more clumsy
> and provide no real benefit. pkg_pretend() should be reserved for
> checks really needed to build packages and not abused to do some early
> output.
> 

I forgot to reply to this.

The benefit of pkg_pretend is that it lets you give a sensible error
message. This is not a complex problem we're asking the user to resolve.
Here's what the error would say if I used pkg_pretend:

  This package supports two different toolkits, gtk2 and gtk3. Please
  choose one and add it to your USE flags for .

Here's what it says with REQUIRED_USE:

  !!! Problem resolving dependencies for x11-drivers/nvidia-drivers
  from @selected
  ... done!

  !!! The ebuild selected to satisfy "x11-drivers/nvidia-drivers" has
  unmet requirements.
  - x11-drivers/nvidia-drivers-352.30::gentoo USE="X multilib tools
  -acpi -gtk2 -gtk3 -pax_kernel -uvm" ABI_X86="64"

  The following REQUIRED_USE flag constraints are unsatisfied:
tools? ( any-of ( gtk2 gtk3 ) )

  The above constraints are a subset of the following complete
  expression:
tools? ( X any-of ( gtk2 gtk3 ) )

We could make the portage output a little better, but that's going to be
an uphill battle and still won't be as informative or short as the
pkg_pretend version.

What we really need is a way to tie an error message to a REQUIRED_USE
clause. I think I remember Ciaran sarcastically suggesting that we make
REQUIRED_USE a dictionary lookup from clause => message. The sarcasm was
probably because all we'd be doing is replacing the if/then/die
statements (that we'd use in pkg_pretend) with ?,(), and => in
REQUIRED_USE. It's an abstraction without any benefit at that point.

Re: [gentoo-dev] [RFC] Global USE=gui

[Michael Orlitzky]

On 06/07/2016 12:20 PM, Michał Górny wrote:
> 
> So many weird ideas... while the simplest one is a proper REQUIRED_USE
> with gui being the control flag, and IUSE defaults to select
> the preferred toolkit.
> 

This is what came to my mind.

The underlying problem that we are hitting (a la Patrick) is that USE
flags are supposed to be a user-interface for building software from
source, but implementation details are an important part of configuring
the software to be built.

It would be nice if USE=gui meant "build a GUI" and that was all the
input that we needed from the user. But if the upstream package supports
both QT and GTK and we need to pass either --with-qt or --with-gtk to
the build system, then there is an unavoidable choice to be made. We can
prefer one, but both options need to be available.

If we want the best of both worlds -- a nice user-interface and full
configurability -- then we can use "the user wants a GUI" as a trigger
for the implementation choice. If there's a default implementation and
the user doesn't care, no further interference should be necessary.
Otherwise the presence of the generic USE=gui will let us know, so we
can let the user know, that he needs to pick one.

Re: [gentoo-dev] [RFC] Global USE=gui

[Michał Górny]

On Mon, 6 Jun 2016 10:53:54 -0400
Ian Stakenvicius  wrote:

> On 04/06/16 01:40 AM, Daniel Campbell wrote:
> > On 06/03/2016 09:07 PM, Ian Stakenvicius wrote:  
> >> On 03/06/16 11:26 PM, Nick Vinson wrote:  
> >>>
> >>> [ Snip! ]  In cases where there's more than 1 option, you have to
> >>> either introduce RESTRICTED_USE as Patrick alluded to, or decide a
> >>> pecking order (or decide who gets to decide the pecking order).  
> >>
> >>
> >> Which dev's already need to do, without USE=gui -- this is not a
> >> deviation from the status quo.
> >>
> >>  
> >>>
> >>> and in that case, it *does* matter what dependencies the gui flag will
> >>> pull in.  Even if the user doesn't care, there's no reason for it to
> >>> pull in version A when version B is also supported by the package and
> >>> every other package with GUI support is using version B.
> >>>  
> >>
> >> And USE=gui is not going to eliminate said choices when there are
> >> choices between toolkits for a package.
> >>  
> >>>
> >>> Some of the proposals on how to handle the case where a package supports
> >>> more than 1 implementation (e.g. supports qt and gtk), lead me to think
> >>> that the gui flag would inadvertently mask how a package was actually
> >>> built and configured. In such a case, troubleshooting is potentially 
> >>> harder.
> >>>
> >>> If that can't (or won't) happen, you can disregard that paragraph.  
> >>
> >>
> >> That can't or won't happen.  NOTHING about the USE=gui proposal turns
> >> deterministic things into automagic things.  It's just about
> >> restructuring the determinism.
> >>
> >> Now, as is the case already for packages like this without a
> >> REQUIRED_USE line, if a package supports just one of both gtk and qt5,
> >> and both flags are enabled, then the package maintainer needs to
> >> determine which one takes precedence and the state of the other will
> >> be ignored.  This isn't ideal since it can amount to useless rebuilds,
> >> but it isn't automagic either.
> >>
> >>
> >>  
> > You touched on the part that I'm most concerned about: choosing. If the
> > 'GUI' USE_EXPAND gets in, do we maintainers check that variable and if
> > there's no preference just build whatever? Will we not be expected to
> > emit an ewarn or something similar to clarify *why* the package is being
> > built a certain way? Granted, if a user has a problem and reports a bug,
> > their make.conf's GUI variable should be present in emerge -v output,
> > easily explaining the issue.  
> 
> 
> A pkg_pretend() message would certainly make sense and IMO be a good
> idea, but again this isn't any different than the situation as it
> stands now WITHOUT a USE=gui.  Regardless I don't see this as a
> blocker to the idea.

Nope, it won't. It will only make things slower, more clumsy
and provide no real benefit. pkg_pretend() should be reserved for
checks really needed to build packages and not abused to do some early
output.

> > It's the implementation that gets me here, not the idea. The idea could
> > be neat and make Gentoo management easier at the expense of some
> > (hopefully) minor ebuild bloat. Another issue that hasn't been covered
> > well yet is how are we going to select DEPENDs? I was told DEPEND
> > doesn't support exactly-one-of, and we don't want extraneous dependencies.  
> 
> 
> ...you lost me on this one... You mean use-flag based operators to
> select atoms in (R)DEPEND ?  Yeah it doesn't but this isn't an issue
> either.  See below:
> 
> 
> > Transmission is a good example: supports gtk3, qt4, qt5. Let's say the
> > maintainer prefers the qt5 version. Would we do this?:
> > 
> > DEPEND="gui_qt5? ( dev-qt/qtcore:5 ) gui_qt4? ( dev-qt/qtcore:4 )
> > gui_gtk3? ( x11-libs/gtk+:3 )"
> > 
> > or this?:
> > 
> > DEPEND="gui_qt5? ( !gui_qt4? ( !gui_gtk3? ( dev-qt/qtcore:5 ) ) )"
> > 
> > (snipping because I don't feel like writing it all out)  
> 
> 
> Putting aside what seems to be a USE_EXPAND, for now, since as far as
> I know that idea was squashed the day it was introduced on irc...
> 
> OK, maintainer prefers the qt5 version as per your assumption, and
> because I haven't looked, we'll assume that transmission's gui is
> optional.  RDEPEND would most likely be:
> 
> RDEPEND="...
>   gui? (
>   gtk3? ( x11-libs/gtk+:3 )
>   !gtk3? (
>   qt4? ( dev-qt/qtcore:4 )
>   !qt4? ( dev-qt/qtcore:5 )
>   )
>   )"
> 
> Note that the -default- doesn't need its own flag, since having qt5
> support be wrapped by a qt5 flag doesn't add anything.  Note also that
> the deps as they stand now should probably be almost identical:
> 
> RDEPEND="...
>   qt5? ( dev-qt/qtcore:5 )
>   !qt5? (
>   gtk3? ( x11-libs/gtk+:3 )
>   !gtk3? (
>   qt4? ( dev-qt/qtcore:4 )
>   )
>   )"
> 
> This -can- be simplified using a REQUIRED_USE to force just-one-of
> gtk3,qt4,qt5 , but you can 

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 07/06/16 10:19 AM, Ian Stakenvicius wrote:
> On 07/06/16 05:19 AM, Patrick Lauer wrote:
>> On 06/06/2016 04:53 PM, Ian Stakenvicius wrote:
>>>
>>> This -can- be simplified using a REQUIRED_USE to force just-one-of
>>> gtk3,qt4,qt5 , but you can technically do the same with USE=gui too --
>>> all you'd need to do is add dependencies for the no-specific-flag case.
>>>
>>> RDEPEND="...
>>> qt5? ( dev-qt/qtcore:5 )
>>> qt4? ( dev-qt/qtcore:4 )
>>> gtk3? ( x11-libs/gtk+:3 )
>>> gui? ( !qt5? ( !qt4? ( !gtk3? ( dev-qt/qtcore:5 ) ) )"
>> Wow, that is wonderfully horrible, and making me a little bit angry ...
>>
>> So USE="-qt5 gui" enables qt5 in this scenario. How is that reasonable?
>>
>>
>> (And as usual I'm now at the stage where I am not sure what problem that
>> we had before we are actually solving ...)
>>
> 
> I didn't like that particular version either, (A) because of what you
> said, and (B) due to it needing a REQUIRED_USE to enforce a
> just-one-of dependency.  But people don't *LIKE* to have layered
> use-flag logic, so...
> 
s/know/like/ on last sentence




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 07/06/16 05:19 AM, Patrick Lauer wrote:
> On 06/06/2016 04:53 PM, Ian Stakenvicius wrote:
>>
>> This -can- be simplified using a REQUIRED_USE to force just-one-of
>> gtk3,qt4,qt5 , but you can technically do the same with USE=gui too --
>> all you'd need to do is add dependencies for the no-specific-flag case.
>>
>> RDEPEND="...
>>  qt5? ( dev-qt/qtcore:5 )
>>  qt4? ( dev-qt/qtcore:4 )
>>  gtk3? ( x11-libs/gtk+:3 )
>>  gui? ( !qt5? ( !qt4? ( !gtk3? ( dev-qt/qtcore:5 ) ) )"
> Wow, that is wonderfully horrible, and making me a little bit angry ...
> 
> So USE="-qt5 gui" enables qt5 in this scenario. How is that reasonable?
> 
> 
> (And as usual I'm now at the stage where I am not sure what problem that
> we had before we are actually solving ...)
> 

I didn't like that particular version either, (A) because of what you
said, and (B) due to it needing a REQUIRED_USE to enforce a
just-one-of dependency.  But people don't know to have layered
use-flag logic, so...





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/06/16 13:27, James Le Cuirot wrote:
> What does that mean?
It means that it is made explicit in some way clearly visible to the
end-user.

> Take www-client/otter, for example. It's a qt5-based browser. It 
> doesn't have the qt5 flag. How can it make the requirement
> explicit?
Otter already makes it explicit via its description: «UI using Qt5».

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXVq//AAoJENQqWdRUGk8BOiIQAJPKsDDOlTHWgXJtZYb+q1JL
rIKUZvUTEAxJ2ubRx6hhU0jhw2THI+9/Nr5A1cNt3sH2gSmssVhH5K+llue0dypC
JDV7Pn9sS4bKQs+iFH32v7P1h5q3YVIsWM01U01IGvtLxerfCe1y1/Clm81VB/Qh
VNkkt1h1i3OuOHSXsys5dCeqhs3aVAQeklKrk0+dYFKiPfyVFnsC70EZlNBGDmn5
4Qfx/gkYe5E//81F+vrg7EJ9sbDWXr6/FuOUlbOz8J+d2JSPhIlxrxf+LXNXdoZZ
m4Zc72Qn5bYxzJTsO6AZ/QiK/NhMP6o87IyPJOp9t8sKuZOroB762JZ2UAuR9E5h
k6vgZjXIgCgi8/XrJzuud3xewltllOJvfERYBqyj5LXj8Bon3tuVt055oFNmnrSg
cF7zg0x+oQLsLM8hfdcOs6NR+GqW49EpqBhD2G5d4vext5++m3qU9as1TDGZc8F5
ViWz8asYlTc2kqcKlCPQ0R4t0osdTAnq5GP3M2VcYN+Xu8j/zvCNyShIqRGNM8jo
TZXy8f5cZmvt2m1x122L5U9bz7DsgCjRZ38B7jBDb2qjetDHUlc1WLWoVMWNoOFe
2bjUc6ASJwS7VwkkXvzmznrQR5MlGs588PLr2w8OozmsCt3GHdZXTk4yOSlSmTvM
sB1IqXgRIuTMFOZP+0Wg
=A/I0
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Global USE=gui

[James Le Cuirot]

On Tue, 7 Jun 2016 13:23:49 +0200
Alexander Berntsen  wrote:

> On 07/06/16 11:27, James Le Cuirot wrote:
> 
> > Some packages require qt5 unconditionally, is that bad too?  
>
> It is if the requirement isn't made explicit.

What does that mean? Take www-client/otter, for example. It's a
qt5-based browser. It doesn't have the qt5 flag. How can it make the
requirement explicit?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] [RFC] Global USE=gui

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/06/16 11:27, James Le Cuirot wrote:
> I don't think that's unreasonable given that it only does that
> when qt4 and gtk3 are disabled.
It is horribly counter-intuitive. -qt5 should never result in qt5.

> Some packages require qt5 unconditionally, is that bad too?
It is if the requirement isn't made explicit.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXVq7EAAoJENQqWdRUGk8BwNkP/0asGItiUp06RUSdtJap/dLl
gMywlasHuS3vB8AxL4M1aXx+F8JRJj7O+SSzc0MZdbGJ+CpNUvAOKQj+I7VmnBGe
k0AV/SFxvugmWdsYeMuOi7l+St6QaQxbjVrH7Sdlh+g9OtQNRKIIsXZ6/jvOSUlv
WQPhbiSzWBNCQYXaHkV2ooY4eCIf3aRZK047EqiXo4jcLWjrfrtYUGEfgmWJ7DIt
zMXHo3I2S7/B6LIOdKSO0h7H4KkOr6tYHi+RdwsNFStNuSEQ+gNbC9Dq1iclvaiP
ljDNE7yDtr+cUEt6XjoGkZcGEuycK1qWnUyB6CJUmWiJCE5vy8QfAn1v4eFp0wII
HcUEf/qHFUxFCfe4QY9S0IQ6aBW0ut57gqB0jWanegm+oyqdfq7V2/N5I/Jz1WR9
okxhgmlEorCoBMOMbNUmHL1Lg1g4TC4I3J4j8KBctUIm5z1eVex3fGWglDttPmx8
Be9K4sv8oHnd01PNmovFBIblOk/q96zdKCgY5zA5mqw7e2LI6flhfgwFikard2Pn
yKBokrgY6a4gqvx0BhCGa2Y7r9ZEqsNGqP+XIFrv9qOD6mUMQj3vL0lEFtg3W0lf
8RLctUGaAGc1eLl7QdjeC3J7hBW2zFKUntxP/8fXrK8jAVmtefRbWjXNqTzzN8Y0
2e4tUmOzXZfSmUmmulro
=/aAN
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Global USE=gui

[James Le Cuirot]

On Tue, 7 Jun 2016 11:19:13 +0200
Patrick Lauer  wrote:

> On 06/06/2016 04:53 PM, Ian Stakenvicius wrote:
> >
> > This -can- be simplified using a REQUIRED_USE to force just-one-of
> > gtk3,qt4,qt5 , but you can technically do the same with USE=gui too
> > -- all you'd need to do is add dependencies for the
> > no-specific-flag case.
> >
> > RDEPEND="...
> > qt5? ( dev-qt/qtcore:5 )
> > qt4? ( dev-qt/qtcore:4 )
> > gtk3? ( x11-libs/gtk+:3 )
> > gui? ( !qt5? ( !qt4? ( !gtk3? ( dev-qt/qtcore:5 ) ) )"  
> Wow, that is wonderfully horrible, and making me a little bit
> angry ...
> 
> So USE="-qt5 gui" enables qt5 in this scenario. How is that
> reasonable?

I don't think that's unreasonable given that it only does that when qt4
and gtk3 are disabled. Some packages require qt5 unconditionally, is
that bad too? I'm not saying I like this, I'm indifferent at best, but
it does makes some sense.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] [RFC] Global USE=gui

[Patrick Lauer]

On 06/06/2016 04:53 PM, Ian Stakenvicius wrote:
>
> This -can- be simplified using a REQUIRED_USE to force just-one-of
> gtk3,qt4,qt5 , but you can technically do the same with USE=gui too --
> all you'd need to do is add dependencies for the no-specific-flag case.
>
> RDEPEND="...
>   qt5? ( dev-qt/qtcore:5 )
>   qt4? ( dev-qt/qtcore:4 )
>   gtk3? ( x11-libs/gtk+:3 )
>   gui? ( !qt5? ( !qt4? ( !gtk3? ( dev-qt/qtcore:5 ) ) )"
Wow, that is wonderfully horrible, and making me a little bit angry ...

So USE="-qt5 gui" enables qt5 in this scenario. How is that reasonable?


(And as usual I'm now at the stage where I am not sure what problem that
we had before we are actually solving ...)

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 04/06/16 01:40 AM, Daniel Campbell wrote:
> On 06/03/2016 09:07 PM, Ian Stakenvicius wrote:
>> On 03/06/16 11:26 PM, Nick Vinson wrote:
>>>
>>> [ Snip! ]  In cases where there's more than 1 option, you have to
>>> either introduce RESTRICTED_USE as Patrick alluded to, or decide a
>>> pecking order (or decide who gets to decide the pecking order).
>>
>>
>> Which dev's already need to do, without USE=gui -- this is not a
>> deviation from the status quo.
>>
>>
>>>
>>> and in that case, it *does* matter what dependencies the gui flag will
>>> pull in.  Even if the user doesn't care, there's no reason for it to
>>> pull in version A when version B is also supported by the package and
>>> every other package with GUI support is using version B.
>>>
>>
>> And USE=gui is not going to eliminate said choices when there are
>> choices between toolkits for a package.
>>
>>>
>>> Some of the proposals on how to handle the case where a package supports
>>> more than 1 implementation (e.g. supports qt and gtk), lead me to think
>>> that the gui flag would inadvertently mask how a package was actually
>>> built and configured. In such a case, troubleshooting is potentially harder.
>>>
>>> If that can't (or won't) happen, you can disregard that paragraph.
>>
>>
>> That can't or won't happen.  NOTHING about the USE=gui proposal turns
>> deterministic things into automagic things.  It's just about
>> restructuring the determinism.
>>
>> Now, as is the case already for packages like this without a
>> REQUIRED_USE line, if a package supports just one of both gtk and qt5,
>> and both flags are enabled, then the package maintainer needs to
>> determine which one takes precedence and the state of the other will
>> be ignored.  This isn't ideal since it can amount to useless rebuilds,
>> but it isn't automagic either.
>>
>>
>>
> You touched on the part that I'm most concerned about: choosing. If the
> 'GUI' USE_EXPAND gets in, do we maintainers check that variable and if
> there's no preference just build whatever? Will we not be expected to
> emit an ewarn or something similar to clarify *why* the package is being
> built a certain way? Granted, if a user has a problem and reports a bug,
> their make.conf's GUI variable should be present in emerge -v output,
> easily explaining the issue.


A pkg_pretend() message would certainly make sense and IMO be a good
idea, but again this isn't any different than the situation as it
stands now WITHOUT a USE=gui.  Regardless I don't see this as a
blocker to the idea.


> 
> It's the implementation that gets me here, not the idea. The idea could
> be neat and make Gentoo management easier at the expense of some
> (hopefully) minor ebuild bloat. Another issue that hasn't been covered
> well yet is how are we going to select DEPENDs? I was told DEPEND
> doesn't support exactly-one-of, and we don't want extraneous dependencies.


...you lost me on this one... You mean use-flag based operators to
select atoms in (R)DEPEND ?  Yeah it doesn't but this isn't an issue
either.  See below:


> Transmission is a good example: supports gtk3, qt4, qt5. Let's say the
> maintainer prefers the qt5 version. Would we do this?:
> 
> DEPEND="gui_qt5? ( dev-qt/qtcore:5 ) gui_qt4? ( dev-qt/qtcore:4 )
> gui_gtk3? ( x11-libs/gtk+:3 )"
> 
> or this?:
> 
> DEPEND="gui_qt5? ( !gui_qt4? ( !gui_gtk3? ( dev-qt/qtcore:5 ) ) )"
> 
> (snipping because I don't feel like writing it all out)


Putting aside what seems to be a USE_EXPAND, for now, since as far as
I know that idea was squashed the day it was introduced on irc...

OK, maintainer prefers the qt5 version as per your assumption, and
because I haven't looked, we'll assume that transmission's gui is
optional.  RDEPEND would most likely be:

RDEPEND="...
gui? (
gtk3? ( x11-libs/gtk+:3 )
!gtk3? (
qt4? ( dev-qt/qtcore:4 )
!qt4? ( dev-qt/qtcore:5 )
)
)"

Note that the -default- doesn't need its own flag, since having qt5
support be wrapped by a qt5 flag doesn't add anything.  Note also that
the deps as they stand now should probably be almost identical:

RDEPEND="...
qt5? ( dev-qt/qtcore:5 )
!qt5? (
gtk3? ( x11-libs/gtk+:3 )
!gtk3? (
qt4? ( dev-qt/qtcore:4 )
)
)"

This -can- be simplified using a REQUIRED_USE to force just-one-of
gtk3,qt4,qt5 , but you can technically do the same with USE=gui too --
all you'd need to do is add dependencies for the no-specific-flag case.

RDEPEND="...
qt5? ( dev-qt/qtcore:5 )
qt4? ( dev-qt/qtcore:4 )
gtk3? ( x11-libs/gtk+:3 )
gui? ( !qt5? ( !qt4? ( !gtk3? ( dev-qt/qtcore:5 ) ) )"

And of course you could also force one of qt5/qt4/gtk3 to be enabled
via REQUIRED_USE if USE=gui is set, as well.

AND, finally, as was alluded to in the original post, it could well be
that we don't want to bother with 

Re: [gentoo-dev] [RFC] Global USE=gui

[Mart Raudsepp]

Ühel kenal päeval, R, 03.06.2016 kell 22:40, kirjutas Daniel Campbell:
> You touched on the part that I'm most concerned about: choosing. If
> the
> 'GUI' USE_EXPAND gets in, do we maintainers check that variable and
> if
> there's no preference just build whatever?

As I don't want this thread to drown in the (imho) cornercase of
multiple choice GUIs, I will cut this into a fully new thread named
"Choosing GUI toolkits from multiple choices" and will reply there for
clean separation.


Mart

Re: [gentoo-dev] [RFC] Global USE=gui

[NP-Hardass]

On 06/02/2016 05:21 PM, Rich Freeman wrote:

On Thu, Jun 2, 2016 at 4:46 PM, Michał Górny  wrote:


We understand that some people have goals like 'I want Qt everywhere,
I hate GTK+ so much I'd rather not be able to do anything than have
GTK+ on my system'. We respect them. But we're no longer going to
optimize Gentoo for those people.



++

I think this is the right direction to take.  Packages should try to
use the appropriate libraries by default (assuming they support more
than one), so the plasma user gets apps linked to qt5, and so on.  The
user shouldn't have to set USE flags to get basic behavior like this -
maybe they just pick a profile.

If a plasma user installs a package that only supports gtk, then it
pulls in gtk.

Users shouldn't need a laundry list of global or per-package USE
settings if they don't really care which libraries they need.  This
reasonable default behavior also shouldn't result in every single
package pulling in every possible optional dependency as well.  It
should just use the "right" one.

If somebody wants to set USE=-* and micromanage every package, well,
that will always work on Gentoo.  However, that should not be the use
case we optimize for.



So, at this juncture, is it worth considering a proper abstraction for 
"suggests" and "optional" and/or "preferred" (for USE and *DEPEND) 
rather than (or in addition to) USE="gui"?


--
NP-Hardass

Re: [gentoo-dev] [RFC] Global USE=gui

[Daniel Campbell]

On 06/03/2016 09:07 PM, Ian Stakenvicius wrote:
> On 03/06/16 11:26 PM, Nick Vinson wrote:
>>
>> [ Snip! ]  In cases where there's more than 1 option, you have to
>> either introduce RESTRICTED_USE as Patrick alluded to, or decide a
>> pecking order (or decide who gets to decide the pecking order).
> 
> 
> Which dev's already need to do, without USE=gui -- this is not a
> deviation from the status quo.
> 
> 
>>
>> and in that case, it *does* matter what dependencies the gui flag will
>> pull in.  Even if the user doesn't care, there's no reason for it to
>> pull in version A when version B is also supported by the package and
>> every other package with GUI support is using version B.
>>
> 
> And USE=gui is not going to eliminate said choices when there are
> choices between toolkits for a package.
> 
>>
>> Some of the proposals on how to handle the case where a package supports
>> more than 1 implementation (e.g. supports qt and gtk), lead me to think
>> that the gui flag would inadvertently mask how a package was actually
>> built and configured. In such a case, troubleshooting is potentially harder.
>>
>> If that can't (or won't) happen, you can disregard that paragraph.
> 
> 
> That can't or won't happen.  NOTHING about the USE=gui proposal turns
> deterministic things into automagic things.  It's just about
> restructuring the determinism.
> 
> Now, as is the case already for packages like this without a
> REQUIRED_USE line, if a package supports just one of both gtk and qt5,
> and both flags are enabled, then the package maintainer needs to
> determine which one takes precedence and the state of the other will
> be ignored.  This isn't ideal since it can amount to useless rebuilds,
> but it isn't automagic either.
> 
> 
> 
You touched on the part that I'm most concerned about: choosing. If the
'GUI' USE_EXPAND gets in, do we maintainers check that variable and if
there's no preference just build whatever? Will we not be expected to
emit an ewarn or something similar to clarify *why* the package is being
built a certain way? Granted, if a user has a problem and reports a bug,
their make.conf's GUI variable should be present in emerge -v output,
easily explaining the issue.

It's the implementation that gets me here, not the idea. The idea could
be neat and make Gentoo management easier at the expense of some
(hopefully) minor ebuild bloat. Another issue that hasn't been covered
well yet is how are we going to select DEPENDs? I was told DEPEND
doesn't support exactly-one-of, and we don't want extraneous dependencies.

Transmission is a good example: supports gtk3, qt4, qt5. Let's say the
maintainer prefers the qt5 version. Would we do this?:

DEPEND="gui_qt5? ( dev-qt/qtcore:5 ) gui_qt4? ( dev-qt/qtcore:4 )
gui_gtk3? ( x11-libs/gtk+:3 )"

or this?:

DEPEND="gui_qt5? ( !gui_qt4? ( !gui_gtk3? ( dev-qt/qtcore:5 ) ) )"

(snipping because I don't feel like writing it all out)

Thing is, what would an empty GUI do? Would we fall back to IUSE? What
if all three are present in GUI? Someone (I forget who) had an idea to
specify priority in the GUI variable. How will that be supported in
ebuilds? With a gui.eclass?

I'm almost to the point with this discussion that we just need a few
blatant, no-op test ebuilds and a portage patch or something to
demonstrate how it would be handled. Code talks a lot better than we do.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Michał Górny]

On Fri, 3 Jun 2016 14:33:16 -0700
Nick Vinson  wrote:

> On Jun 3, 2016 1:15 PM, "Alan McKinnon"  wrote:
> >
> > On 03/06/2016 21:34, waltd...@waltdnes.org wrote:  
> >>
> >> On Fri, Jun 03, 2016 at 10:35:45AM -0400, Ian Stakenvicius wrote
> >>  
> >>> USE=gui is about building the graphical user interface that an
> >>> application offers, when it is optional.  That's it.  What
> >>> dependencies that means and so on have nothing to do with the flag.  
> >>
> >>
> >>That reasoning may have been valid many years ago when qt was the only
> >> toolkit around.  All GUI-optional apps back then either used qt or wrote
> >> their own primitives directly to X.  Fast-forward to 2016.  You now have
> >> X/Wayland/Mir/qt4/qt5/gtk2/gtk3/fltk/whatever.  If a package can have a
> >> GUI from more than one of the above, you *NEED* to select implementation
> >> type *SOMEWHERE* (make.conf/package.use/profile).  Deal with it.
> >>  
> >>> You get that use flags are not supposed to represent dependencies
> >>> right, but features of the package??  
> >>
> >>
> >>Gentoo currently assumes that users are reasonably competent, and that
> >> if they've selected specific graphics libs to be linked to a package,
> >> that they've done it for a reason; i.e. to enable a GUI.  
> >
> >
> > Walter,
> >
> > I think you're missing where the devs want to take this and what USE is  
> all about. It's about *features*, not about dependencies.
> >
> > USE="gtk" is a dependency.  
> 
> No.  It is a feature.  However, it is a feature named after the
> dependencies needed to enable it.  If a package has a hard dependency on
> libgtk, a USE flag would not be added, but a soft dependency on libgtk
> means that libgtk support is a feature or part of a feature (the feature
> being you get to choose which toolkit is used).
> 
> If it was a dependency, then packages such as XFCE and evince would have to
> use flags.  However they don't.
> 
> So enough with the these are dependency use flags and those are feature use
> flags.  It's not true and it's a poor attempt to try and force this idea
> through.  If this is idea is a good one, such tactics aren't needed.  If
> it's not, the tactics aren't warranted.

Your statement is not true and is a poor attempt to try and block
the idea you don't like. If it would be a bad one, such tactics
wouldn't be needed on your side...

-- 
Best regards,
Michał Górny



pgpl41ALcRGnN.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 03/06/16 11:26 PM, Nick Vinson wrote:
> 
> [ Snip! ]  In cases where there's more than 1 option, you have to
> either introduce RESTRICTED_USE as Patrick alluded to, or decide a
> pecking order (or decide who gets to decide the pecking order).


Which dev's already need to do, without USE=gui -- this is not a
deviation from the status quo.


> 
> and in that case, it *does* matter what dependencies the gui flag will
> pull in.  Even if the user doesn't care, there's no reason for it to
> pull in version A when version B is also supported by the package and
> every other package with GUI support is using version B.
> 

And USE=gui is not going to eliminate said choices when there are
choices between toolkits for a package.

> 
> Some of the proposals on how to handle the case where a package supports
> more than 1 implementation (e.g. supports qt and gtk), lead me to think
> that the gui flag would inadvertently mask how a package was actually
> built and configured. In such a case, troubleshooting is potentially harder.
> 
> If that can't (or won't) happen, you can disregard that paragraph.


That can't or won't happen.  NOTHING about the USE=gui proposal turns
deterministic things into automagic things.  It's just about
restructuring the determinism.

Now, as is the case already for packages like this without a
REQUIRED_USE line, if a package supports just one of both gtk and qt5,
and both flags are enabled, then the package maintainer needs to
determine which one takes precedence and the state of the other will
be ignored.  This isn't ideal since it can amount to useless rebuilds,
but it isn't automagic either.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Nick Vinson]

On 06/03/2016 07:35 AM, Ian Stakenvicius wrote:
> On 02/06/16 09:48 PM, Nick Vinson wrote:
>> On 06/02/2016 08:08 AM, Raymond Jennings wrote:
>>> use case:  Telling a package to build a gui without deciding which one
>>> to build.  Also helps in cases where you have package A that can only
>>> build a qt gui, and package B that can build both qt and gtk, and
>>> package C that can build gtk only.  You want to have a gui for all
>>> three, but you don't want to hav epackage B build both guis and at the
>>> same time while you may prefer qt, you don't want to leave package C
>>> without a gui.
>>
>> How do you decide which one package B builds in such a case?
>>
>> Honestly, I don't think this is a good idea.  The rationale  and
>> suggested implementation just don't bring enough benefit in my opinion.
>> Often times it's hard enough to research a reported issue with the
>> current implementation.  Having a flag like 'gui' whose behavior
>> (potentially) changes based on what profile is being used makes things
>> considerably harder.  It would no longer be a simple matter of matching
>> versions and USE flags, the package maintainer would also need to setup
>> an equivalent system with the same profile or research what the 'gui'
>> flag with profile 'x' does and setup an equivalent USE flag set.
> 
> 
> OK this makes absolutely no sense.
> 
> USE=gui is about building the graphical user interface that an
> application offers, when it is optional.  That's it.  What
> dependencies that means and so on have nothing to do with the flag.

Which only works with packages that provide support for a single GUI
implementation.  In cases where there's more than 1 option, you have to
either introduce RESTRICTED_USE as Patrick alluded to, or decide a
pecking order (or decide who gets to decide the pecking order).

and in that case, it *does* matter what dependencies the gui flag will
pull in.  Even if the user doesn't care, there's no reason for it to
pull in version A when version B is also supported by the package and
every other package with GUI support is using version B.

> It's the same as USE="server" to build the server daemon for an app
> that provides both client and server.

Maybe if IPX was still popular and I had to be concerned about whether
"server" would favor a TCP/IP server or an IPX one, but that's not the
case, so I don't see the two being equivalent here.

In fact, I see this flag more like the 'dedicated' USE flag (which in my
opinion, causes more problems than it solves).

> 
> You get that use flags are not supposed to represent dependencies
> right, but features of the package??  If you're only able to debug a
> build of your package because the flag is called gtk instead of gui,
> well...

I'm well aware how use flags are supposed to work, thank you.  Also had
you actually read what I had wrote and the context surrounding it, you
probably wouldn't have made such an asinine remark.

> 
> 
>>
>> Gentoo already has Gnome, KDE, Plasma, and Desktop profiles which mostly
>> do the same thing.  The only thing they don't do (as I understand the
>> profiles) is enable GUI support for packages that don't support the
>> preferred libraries.  Is that really enough justification to implement
>> this flag?
> 
> Yes.
> 
> More specifically, the cleanup of all of those other uses of flags
> that are there just to trigger a gui build instead of to indicate a
> choice between options, is also enough justification.  Think about a
> wayland system -- there's lots of packages that IUSE="X" to build
> their gui implementation.  If someone wanting wayland set USE="-X"
> then they don't get the gui app even if it'll work in wayland just fine.
> 
> Yes, the USE=gui on this hypothetical app may well pull in Xorg libs,
> but that's not a reason to keep the flag called "X", because again,
> its about the feature of the package *not* the dependency.

Sure it is.  The feature is supporting X11 not Wayland or some
hypothetical "omnigui".  Do you really think upstream is going to care
if their X11 app fails to work correct correctly in Wayland,  but runs
fine in a native X11 setup?

I tunnel X11 over ssh all the time, do you really think it makes more
since for me to have to set the 'gui' flag to do this instead of the X flag?

Yes, I agree that the 'X' flag should control a feature.  For most
packages, that feature is integrating with an X11 environment (i.e.
providing X11 bindings) and for most packages the X11 feature introduces
dependencies on the X11 libraries.  The gui flag won't change that.

Nor does it make sense to rename 'X' to gui just because a Wayland user
misconfigured his system.  In your scenario, the user requested that the
packages not be built with the X feature, so that's what they got.  The
fact that it would have otherwise worked with Wayland is immaterial.

> 
>
>>
>> As a maintainer I'd ask that, at the very least, a more compelling
>> reason than "it's too annoying to update package.use" is given.  I 

Re: [gentoo-dev] [RFC] Global USE=gui

[Alan McKinnon]

On 03/06/2016 23:33, Nick Vinson wrote:

 > USE="gtk" is a dependency.

No.  It is a feature.  However, it is a feature named after the
dependencies needed to enable it.  If a package has a hard dependency on
libgtk, a USE flag would not be added, but a soft dependency on libgtk
means that libgtk support is a feature or part of a feature (the feature
being you get to choose which toolkit is used).

If it was a dependency, then packages such as XFCE and evince would have
to use flags.  However they don't.

So enough with the these are dependency use flags and those are feature
use flags.  It's not true and it's a poor attempt to try and force this
idea through.  If this is idea is a good one, such tactics aren't
needed.  If it's not, the tactics aren't warranted.




Well, that's your opinion and thank you for stating it. I stated mine, 
and neither are facts.


Alan

Re: [gentoo-dev] [RFC] Global USE=gui

[Nick Vinson]

On Jun 3, 2016 1:15 PM, "Alan McKinnon"  wrote:
>
> On 03/06/2016 21:34, waltd...@waltdnes.org wrote:
>>
>> On Fri, Jun 03, 2016 at 10:35:45AM -0400, Ian Stakenvicius wrote
>>
>>> USE=gui is about building the graphical user interface that an
>>> application offers, when it is optional.  That's it.  What
>>> dependencies that means and so on have nothing to do with the flag.
>>
>>
>>That reasoning may have been valid many years ago when qt was the only
>> toolkit around.  All GUI-optional apps back then either used qt or wrote
>> their own primitives directly to X.  Fast-forward to 2016.  You now have
>> X/Wayland/Mir/qt4/qt5/gtk2/gtk3/fltk/whatever.  If a package can have a
>> GUI from more than one of the above, you *NEED* to select implementation
>> type *SOMEWHERE* (make.conf/package.use/profile).  Deal with it.
>>
>>> You get that use flags are not supposed to represent dependencies
>>> right, but features of the package??
>>
>>
>>Gentoo currently assumes that users are reasonably competent, and that
>> if they've selected specific graphics libs to be linked to a package,
>> that they've done it for a reason; i.e. to enable a GUI.
>
>
> Walter,
>
> I think you're missing where the devs want to take this and what USE is
all about. It's about *features*, not about dependencies.
>
> USE="gtk" is a dependency.

No.  It is a feature.  However, it is a feature named after the
dependencies needed to enable it.  If a package has a hard dependency on
libgtk, a USE flag would not be added, but a soft dependency on libgtk
means that libgtk support is a feature or part of a feature (the feature
being you get to choose which toolkit is used).

If it was a dependency, then packages such as XFCE and evince would have to
use flags.  However they don't.

So enough with the these are dependency use flags and those are feature use
flags.  It's not true and it's a poor attempt to try and force this idea
through.  If this is idea is a good one, such tactics aren't needed.  If
it's not, the tactics aren't warranted.

> USE="gui" is a feature.
> You only need enable a specific graphics lib flag when there is ambiguity
about what "gui" means for a package.
>
>
>>
>>> Think about a wayland system -- there's lots of packages that
>>> IUSE="X" to build their gui implementation.  If someone wanting
>>> wayland set USE="-X" then they don't get the gui app even if it'll
>>> work in wayland just fine.
>>
>>
>>If someone wants to run a wayland system, why wouldn't they set
>> USE="-X -mir wayland" in make.conf in the first place?!?!?
>>
>>Here's my problem with USE="gui"... I've set up various packages which
>> have the gui/no-gui option.  If USE="-gui" overrides USE="X gtk3 qt4
fltk",
>> then I would have to set USE="gui" *IN ADDITION TO* telling packages
>> which GUI toolkit to use.  Since I may want some packages GUI, and some
>> non-GUI, that would be one more USE flag to set in package.use and/or
>> make.conf.
>>
>>The reason for the pushback is that this "feature" would be rammed
>> down peoples' throats, Poettering-style.  I propose a compromise
>> solution that both sides should be happy with.  It would require 2 USE
>> flags, namely "forcegui" and "forcenogui".
>>
>>If "forcegui" is set, all optional-GUI apps will be built with GUIs,
>> regardless of USE="-X -Mir -Wayland -gtk2 -gtk3 -qt4 -qt5".
>>
>>If "forcenogui" is set, no optional-GUI apps will be built with GUIs,
>> regardless of USE="X Mir Wayland gtk2 gtk3 qt4 qt5".
>>
>>If USE="-forcegui -forcenogui" is set, things will be as they are
>> today.  GUIs will be built, or not, depending on what toolkit flags are
>> set or not set.  Gentoo is about choice.
>>
>
> That's a silly idea not least because it's non-deterministic. A force USE
flag is really just USE="gtk" or USE="qt" on a larger scale as there's now
*more* toolkits to randomly pick one from.
>
> Most apps support one toolkit, often either gtk2/3 or qt4/5. It's a
minority that support both and we have special means to handle those. For
that small set of apps that do support several toolkits, what exactly are
you going to force? If you can have one of gtk 2 or 3 but not both, which
one is it? Well you'd need a USE="gtk2" or USE="gtk3" to find out what the
user wants.
>
> This proposal makes things simpler and reduces flags and their usage.
> "gui" means build the gui the thing supports.
> "X" stops meaning "gui" or maybe "XLibs" or perhaps "usually RDP but also
supports magic X11" and starts to mean "X11 Window System" as opposed to
Wayland or Mir.
> The other toolkit flags start to mean specific versions of toolkits and
only need be used when things get ambiguous and portage wants you you tell
it what you want.
>
> In short, flags will get simpler (as cruft will be removed) and flags
gain clearer distinct names. Think of it as a code refactor after years of
accumulating rubbish due to no clear plan.
>
> Alan
>
>
>

Re: [gentoo-dev] [RFC] Global USE=gui

[M. J. Everitt]

On 03/06/16 21:13, Alan McKinnon wrote:
> Walter,
>
> I think you're missing where the devs want to take this and what USE
> is all about. It's about *features*, not about dependencies.
>
> USE="gtk" is a dependency.
> USE="gui" is a feature.
> You only need enable a specific graphics lib flag when there is
> ambiguity about what "gui" means for a package.
>

> Most apps support one toolkit, often either gtk2/3 or qt4/5. It's a
> minority that support both and we have special means to handle those.
> For that small set of apps that do support several toolkits, what
> exactly are you going to force? If you can have one of gtk 2 or 3 but
> not both, which one is it? Well you'd need a USE="gtk2" or USE="gtk3"
> to find out what the user wants.
>
> This proposal makes things simpler and reduces flags and their usage.
> "gui" means build the gui the thing supports.
> "X" stops meaning "gui" or maybe "XLibs" or perhaps "usually RDP but
> also supports magic X11" and starts to mean "X11 Window System" as
> opposed to Wayland or Mir.
> The other toolkit flags start to mean specific versions of toolkits
> and only need be used when things get ambiguous and portage wants you
> you tell it what you want.
>
> In short, flags will get simpler (as cruft will be removed) and flags
> gain clearer distinct names. Think of it as a code refactor after
> years of accumulating rubbish due to no clear plan.
>
> Alan
>
>
>
+1, thanks for the sensible explanation.

I guess it's going to take a while to push the update through the tree,
but I think the clarification is useful where other USE flags have been
previously abused ... use flag abuse is bad generally !



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Alan McKinnon]

On 03/06/2016 21:34, waltd...@waltdnes.org wrote:

On Fri, Jun 03, 2016 at 10:35:45AM -0400, Ian Stakenvicius wrote


USE=gui is about building the graphical user interface that an
application offers, when it is optional.  That's it.  What
dependencies that means and so on have nothing to do with the flag.


   That reasoning may have been valid many years ago when qt was the only
toolkit around.  All GUI-optional apps back then either used qt or wrote
their own primitives directly to X.  Fast-forward to 2016.  You now have
X/Wayland/Mir/qt4/qt5/gtk2/gtk3/fltk/whatever.  If a package can have a
GUI from more than one of the above, you *NEED* to select implementation
type *SOMEWHERE* (make.conf/package.use/profile).  Deal with it.


You get that use flags are not supposed to represent dependencies
right, but features of the package??


   Gentoo currently assumes that users are reasonably competent, and that
if they've selected specific graphics libs to be linked to a package,
that they've done it for a reason; i.e. to enable a GUI.


Walter,

I think you're missing where the devs want to take this and what USE is 
all about. It's about *features*, not about dependencies.


USE="gtk" is a dependency.
USE="gui" is a feature.
You only need enable a specific graphics lib flag when there is 
ambiguity about what "gui" means for a package.





Think about a wayland system -- there's lots of packages that
IUSE="X" to build their gui implementation.  If someone wanting
wayland set USE="-X" then they don't get the gui app even if it'll
work in wayland just fine.


   If someone wants to run a wayland system, why wouldn't they set
USE="-X -mir wayland" in make.conf in the first place?!?!?

   Here's my problem with USE="gui"... I've set up various packages which
have the gui/no-gui option.  If USE="-gui" overrides USE="X gtk3 qt4 fltk",
then I would have to set USE="gui" *IN ADDITION TO* telling packages
which GUI toolkit to use.  Since I may want some packages GUI, and some
non-GUI, that would be one more USE flag to set in package.use and/or
make.conf.

   The reason for the pushback is that this "feature" would be rammed
down peoples' throats, Poettering-style.  I propose a compromise
solution that both sides should be happy with.  It would require 2 USE
flags, namely "forcegui" and "forcenogui".

   If "forcegui" is set, all optional-GUI apps will be built with GUIs,
regardless of USE="-X -Mir -Wayland -gtk2 -gtk3 -qt4 -qt5".

   If "forcenogui" is set, no optional-GUI apps will be built with GUIs,
regardless of USE="X Mir Wayland gtk2 gtk3 qt4 qt5".

   If USE="-forcegui -forcenogui" is set, things will be as they are
today.  GUIs will be built, or not, depending on what toolkit flags are
set or not set.  Gentoo is about choice.



That's a silly idea not least because it's non-deterministic. A force 
USE flag is really just USE="gtk" or USE="qt" on a larger scale as 
there's now *more* toolkits to randomly pick one from.


Most apps support one toolkit, often either gtk2/3 or qt4/5. It's a 
minority that support both and we have special means to handle those. 
For that small set of apps that do support several toolkits, what 
exactly are you going to force? If you can have one of gtk 2 or 3 but 
not both, which one is it? Well you'd need a USE="gtk2" or USE="gtk3" to 
find out what the user wants.


This proposal makes things simpler and reduces flags and their usage.
"gui" means build the gui the thing supports.
"X" stops meaning "gui" or maybe "XLibs" or perhaps "usually RDP but 
also supports magic X11" and starts to mean "X11 Window System" as 
opposed to Wayland or Mir.
The other toolkit flags start to mean specific versions of toolkits and 
only need be used when things get ambiguous and portage wants you you 
tell it what you want.


In short, flags will get simpler (as cruft will be removed) and flags 
gain clearer distinct names. Think of it as a code refactor after years 
of accumulating rubbish due to no clear plan.


Alan

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Fri, Jun 03, 2016 at 10:35:45AM -0400, Ian Stakenvicius wrote

> USE=gui is about building the graphical user interface that an
> application offers, when it is optional.  That's it.  What
> dependencies that means and so on have nothing to do with the flag.

  That reasoning may have been valid many years ago when qt was the only
toolkit around.  All GUI-optional apps back then either used qt or wrote
their own primitives directly to X.  Fast-forward to 2016.  You now have
X/Wayland/Mir/qt4/qt5/gtk2/gtk3/fltk/whatever.  If a package can have a
GUI from more than one of the above, you *NEED* to select implementation
type *SOMEWHERE* (make.conf/package.use/profile).  Deal with it.

> You get that use flags are not supposed to represent dependencies
> right, but features of the package??

  Gentoo currently assumes that users are reasonably competent, and that
if they've selected specific graphics libs to be linked to a package,
that they've done it for a reason; i.e. to enable a GUI.

> Think about a wayland system -- there's lots of packages that
> IUSE="X" to build their gui implementation.  If someone wanting
> wayland set USE="-X" then they don't get the gui app even if it'll
> work in wayland just fine.

  If someone wants to run a wayland system, why wouldn't they set
USE="-X -mir wayland" in make.conf in the first place?!?!?

  Here's my problem with USE="gui"... I've set up various packages which
have the gui/no-gui option.  If USE="-gui" overrides USE="X gtk3 qt4 fltk",
then I would have to set USE="gui" *IN ADDITION TO* telling packages
which GUI toolkit to use.  Since I may want some packages GUI, and some
non-GUI, that would be one more USE flag to set in package.use and/or
make.conf.

  The reason for the pushback is that this "feature" would be rammed
down peoples' throats, Poettering-style.  I propose a compromise
solution that both sides should be happy with.  It would require 2 USE
flags, namely "forcegui" and "forcenogui".

  If "forcegui" is set, all optional-GUI apps will be built with GUIs,
regardless of USE="-X -Mir -Wayland -gtk2 -gtk3 -qt4 -qt5".

  If "forcenogui" is set, no optional-GUI apps will be built with GUIs,
regardless of USE="X Mir Wayland gtk2 gtk3 qt4 qt5".

  If USE="-forcegui -forcenogui" is set, things will be as they are
today.  GUIs will be built, or not, depending on what toolkit flags are
set or not set.  Gentoo is about choice.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Global USE=gui

[Patrick Lauer]

On 06/03/2016 10:52 AM, Michał Górny wrote:
> Dnia 2 czerwca 2016 21:36:10 CEST, waltd...@waltdnes.org napisał(a):
>>
>>  Is it broken right now?  What improvement will we see from having to
>> add a "GUI" flag?
> TL;DR: it's broken as hell, missing GUI, flag conflicts, implicit flags, full 
> package.use and inability to sanely replace old toolkits with new ones.
I see it the other way around: Adding Yet Another Flag will just make
things more, uhm, exciting.

For example since gtk3 is totally useless on HiDPI and only mostly
useless on normal screens I want to actively avoid it. Having a 'gui'
useflag adds another indirection that badly emulates what the profile
already does ...

> So, let's say we're considering only GTK+ and Qt, for simplicity's sake. Wrt 
> QA policy, we only are supposed to use the following flags: gtk2, gtk3, qt4, 
> qt5...
>
> Now, we have the major types of packages (with some GUI):
>
> 1. Packages with a single obligatory GUI -- having no flags,
>
> 2. packages with a single optional GUI -- having one flag controlling whether 
> it is enabled,
But is it gtk2 or gtk3? If 2 then I'm ok, if 3 then not, now I can't
easily see what is pulling in the wrong deps
>
> 3. packages with multiple GUIs -- having multiple flags.
>
> Now, the third type could be further split depending on:
So now dependencies become funny ...

RDEPEND="gui? ( X? ( gtk2? ( ...) gtk3? ( ...)))"
REQUIRED_USE="gui? ( ^^ ( gtk2 gtk3 ))"

See how gui just adds a middle layer that doesn't help most cases? Sigh. :\

[snip]
> Let's say he underwent the effort and enabled gtk2 on some packages, qt5 on 
> some other.
>
> Now, when packages gain gtk3 support, he either gets new conflicts or two 
> flags being enabled cause app to prefer one of them. When packages gain qt6 
> support, he is stuck with 5 until support for 5 is removed. Even though some 
> packages start using 6 implicitly anyway.
Which is good / expected: If I deviate from defaults, then don't change
the defaults for me. If I wanted you to decide for me I'd Ubuntu all day
long ;)
>
>
> B. */* gtk3 qt5
>
> This covers packages not supporting GTK+ better but leaves multiple GTK+ 
> problem unsolved. But now, some packages will either request him to disable 
> one of the two, or implicitly choose one of them, possibly the one less 
> preferred.
>
>
> C. */* gtk2 gtk3 qt5
>
> Because he is tired with a lot of packages not supporting GTK+3. Now, he's 
> either in a world full of conflicts, or implicit choices. For the latter, 
> he's unhappy that some developers make him prefer old GTK+2.
Implicit is usually wrong, so the packages should have an explicit
one-of-enabled check ... even if it's not the most aesthetical solution.
Otherwise, why have the useflags if you decide for the user?
>
>
> Of course, that are just the closest user facing problems. Additionally, 
> every time developer refuses to use REQUIRED_USE, the user is left with some 
> implicit choice whose result can't be predicted, possibly slow and unreadable 
> pkg_pretend that actually tells him about the choice (too late), and multiple 
> meaningless flag combinations that make it impossible to reuse the same 
> binary package even though the same GUI has been actually used.
>
>
> I'm not saying that 'gui' solves all the problems. But it's a step in the 
> right direction where USE flags actually start meaning something and not 
> resembling the Ubuntu 'apt-get install libgtk+3 libfoo ...'

I kinda disagree that it solves any problems we have, and makes my life
more exciting. And exciting can be bad for my mood ;)

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 02/06/16 09:48 PM, Nick Vinson wrote:
> On 06/02/2016 08:08 AM, Raymond Jennings wrote:
>> use case:  Telling a package to build a gui without deciding which one
>> to build.  Also helps in cases where you have package A that can only
>> build a qt gui, and package B that can build both qt and gtk, and
>> package C that can build gtk only.  You want to have a gui for all
>> three, but you don't want to hav epackage B build both guis and at the
>> same time while you may prefer qt, you don't want to leave package C
>> without a gui.
> 
> How do you decide which one package B builds in such a case?
> 
> Honestly, I don't think this is a good idea.  The rationale  and
> suggested implementation just don't bring enough benefit in my opinion.
> Often times it's hard enough to research a reported issue with the
> current implementation.  Having a flag like 'gui' whose behavior
> (potentially) changes based on what profile is being used makes things
> considerably harder.  It would no longer be a simple matter of matching
> versions and USE flags, the package maintainer would also need to setup
> an equivalent system with the same profile or research what the 'gui'
> flag with profile 'x' does and setup an equivalent USE flag set.


OK this makes absolutely no sense.

USE=gui is about building the graphical user interface that an
application offers, when it is optional.  That's it.  What
dependencies that means and so on have nothing to do with the flag.
It's the same as USE="server" to build the server daemon for an app
that provides both client and server.

You get that use flags are not supposed to represent dependencies
right, but features of the package??  If you're only able to debug a
build of your package because the flag is called gtk instead of gui,
well...


> 
> Gentoo already has Gnome, KDE, Plasma, and Desktop profiles which mostly
> do the same thing.  The only thing they don't do (as I understand the
> profiles) is enable GUI support for packages that don't support the
> preferred libraries.  Is that really enough justification to implement
> this flag?

Yes.

More specifically, the cleanup of all of those other uses of flags
that are there just to trigger a gui build instead of to indicate a
choice between options, is also enough justification.  Think about a
wayland system -- there's lots of packages that IUSE="X" to build
their gui implementation.  If someone wanting wayland set USE="-X"
then they don't get the gui app even if it'll work in wayland just fine.

Yes, the USE=gui on this hypothetical app may well pull in Xorg libs,
but that's not a reason to keep the flag called "X", because again,
its about the feature of the package *not* the dependency.


> 
> As a maintainer I'd ask that, at the very least, a more compelling
> reason than "it's too annoying to update package.use" is given.  I find
> the argument against putting all the flags in global a valid but weak as
> there are already mitigations for that scenario.   Perhaps I'm missing
> something, but I'm not convinced this will provide a significant enough
> benefit to the average Gentoo user to offset the increased
> troubleshooting demand it'll put on Gentoo's developers, maintainers,
> and proxy-maintainers.


Again, you will very much need to elaborate on what these increased
troubleshooting demands are.  If anything, I see this flag, which will
allow the various tooklit flags to just mean a choice between
toolkits, to make things *easier* for troubleshooting, not harder.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Gordon Pettey]

On Fri, Jun 3, 2016 at 8:06 AM, Damien Levac  wrote:

> On 2016-06-02 05:27 PM, Daniel Campbell wrote:
>
>> On 06/02/2016 12:57 PM, Damien Levac wrote:
>>
>>>
>>> On 2016-06-02 03:42 PM, waltd...@waltdnes.org wrote:
>>>
 On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote

> IMHO, you see this in reverse. the 'gui' useflag would be useful for
> users who don't want to care about X/wayland/mir and do not want to
> care
> about gtk/qt, they just want windows to be drawn for the applications
> they install -- without, if possible, pulling useless dependencies.
>
 How, exactly, will the app draw windows without linking against one
 of
 X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
 pike?

>>> It will be linked to one of those, but the users don't want to care so
>>> reasonable default would apply.
>>>
>>> For example, if I have setup my profile to be 'plasma', then having
>>> 'gui' in my global use flags would mean "build with qt5 support to
>>> provide my gui whenever possible, if not possible, fallback to whatever
>>> is available at the discretion of the package maintainer".
>>>
>>> 2 nice properties I foresee this feature will have:
>>>
>>> * If you do not like it, don't use it. It shouldn't affect any user
>>> unless they explicitly use the flag.
>>> * Negating the flag would mean to not build any GUI (i.e. headless
>>> server) which is cleaner than: '-qt3support -qt4 -qt5 -gtk -gtk3 -X
>>> -waylang...'
>>>
>>> I do not think the question is whether the flag would be useful: it
>>> will. The question is: can it be implemented efficiently...
>>>
>> To play devil's advocate, can we get a citation on "users don't want to
>> care"? Which users? Does Gentoo have a lot of users who don't care, or
>> does it attract a more passionate audience that enjoys the control that
>> comes with being source-based? I'm inclined to believe the latter, but
>> I'm ready to be wrong.
>>
> Personal experience: I use to care a lot and tweak my system a lot... But
> I am not an eager undergraduate anymore, my interests have shift. I still
> use Gentoo as I know the system very well and like it. But I am in a point
> in my life where I want to focus on my work and not on whether or not I am
> making a 'gtk-only' or 'qt-only' system..
>
I'm a USE="-*" person, and I think USE="gui" to clean up a few lines in
package.use/* would be a nice idea... We do exist :)

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 02/06/16 05:27 PM, Daniel Campbell wrote:
> To play devil's advocate, can we get a citation on "users don't want to
> care"? Which users? Does Gentoo have a lot of users who don't care, or
> does it attract a more passionate audience that enjoys the control that
> comes with being source-based? I'm inclined to believe the latter, but
> I'm ready to be wrong.
> 

Me. I don't care in 99% of cases.  The only time I do care is when
there's a choice between one or the other.  More specifically, I *DO*
care when I expect to get a gui app installed, but I don't get one at
all, because I didn't have the correct toolkit flag enabled.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Damien Levac]

On 2016-06-02 05:27 PM, Daniel Campbell wrote:

On 06/02/2016 12:57 PM, Damien Levac wrote:


On 2016-06-02 03:42 PM, waltd...@waltdnes.org wrote:

On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote

IMHO, you see this in reverse. the 'gui' useflag would be useful for
users who don't want to care about X/wayland/mir and do not want to care
about gtk/qt, they just want windows to be drawn for the applications
they install -- without, if possible, pulling useless dependencies.

How, exactly, will the app draw windows without linking against one of
X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
pike?

It will be linked to one of those, but the users don't want to care so
reasonable default would apply.

For example, if I have setup my profile to be 'plasma', then having
'gui' in my global use flags would mean "build with qt5 support to
provide my gui whenever possible, if not possible, fallback to whatever
is available at the discretion of the package maintainer".

2 nice properties I foresee this feature will have:

* If you do not like it, don't use it. It shouldn't affect any user
unless they explicitly use the flag.
* Negating the flag would mean to not build any GUI (i.e. headless
server) which is cleaner than: '-qt3support -qt4 -qt5 -gtk -gtk3 -X
-waylang...'

I do not think the question is whether the flag would be useful: it
will. The question is: can it be implemented efficiently...



To play devil's advocate, can we get a citation on "users don't want to
care"? Which users? Does Gentoo have a lot of users who don't care, or
does it attract a more passionate audience that enjoys the control that
comes with being source-based? I'm inclined to believe the latter, but
I'm ready to be wrong.

Personal experience: I use to care a lot and tweak my system a lot... 
But I am not an eager undergraduate anymore, my interests have shift. I 
still use Gentoo as I know the system very well and like it. But I am in 
a point in my life where I want to focus on my work and not on whether 
or not I am making a 'gtk-only' or 'qt-only' system...

Re: [gentoo-dev] [RFC] Global USE=gui

[Michał Górny]

Dnia 2 czerwca 2016 21:36:10 CEST, waltd...@waltdnes.org napisał(a):
>On Thu, Jun 02, 2016 at 06:50:59AM +0100, Graham Murray wrote
>> waltd...@waltdnes.org writes:
>> 
>> >   Let me re-phrase my question... is there *ANY* set of
>circumstances
>> > under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE
>flag
>> > can be set for a package *WITHOUT* requiring a gui?
>> 
>> Yes. X/xorg could be needed to incorporate the X Client libraries so
>> that X servers can connect to it but not itself have a gui. This
>> could, for example, be on a headless server.
>
>  Is it broken right now?  What improvement will we see from having to
>add a "GUI" flag?

TL;DR: it's broken as hell, missing GUI, flag conflicts, implicit flags, full 
package.use and inability to sanely replace old toolkits with new ones.

So, let's say we're considering only GTK+ and Qt, for simplicity's sake. Wrt QA 
policy, we only are supposed to use the following flags: gtk2, gtk3, qt4, qt5...

Now, we have the major types of packages (with some GUI):

1. Packages with a single obligatory GUI -- having no flags,

2. packages with a single optional GUI -- having one flag controlling whether 
it is enabled,

3. packages with multiple GUIs -- having multiple flags.

Now, the third type could be further split depending on:

a. whether it can install multiple GUIs simultaneously, or just one of them,

b. whether the GUI is obligatory or optional -- i.e. if there are flag 
combinations leaving you with no GUI,

c. whether REQUIRED_USE is used to enforce clear choice, or multiple flag 
combinations are collapsed implicitly.

That's there packaging theory. Now let's say that we have a user who wants to 
have GUI built whenever possible, and prefers GTK+3 for some reason.

Now, if he sets:

A. */* gtk3

he will get some packages with GTK+3 GUI, some packages with other GUI, some 
packages with no GUI at all and some packages telling him to enable another 
flag.

Let's say he underwent the effort and enabled gtk2 on some packages, qt5 on 
some other.

Now, when packages gain gtk3 support, he either gets new conflicts or two flags 
being enabled cause app to prefer one of them. When packages gain qt6 support, 
he is stuck with 5 until support for 5 is removed. Even though some packages 
start using 6 implicitly anyway.


B. */* gtk3 qt5

This covers packages not supporting GTK+ better but leaves multiple GTK+ 
problem unsolved. But now, some packages will either request him to disable one 
of the two, or implicitly choose one of them, possibly the one less preferred.


C. */* gtk2 gtk3 qt5

Because he is tired with a lot of packages not supporting GTK+3. Now, he's 
either in a world full of conflicts, or implicit choices. For the latter, he's 
unhappy that some developers make him prefer old GTK+2.


Of course, that are just the closest user facing problems. Additionally, every 
time developer refuses to use REQUIRED_USE, the user is left with some implicit 
choice whose result can't be predicted, possibly slow and unreadable 
pkg_pretend that actually tells him about the choice (too late), and multiple 
meaningless flag combinations that make it impossible to reuse the same binary 
package even though the same GUI has been actually used.


I'm not saying that 'gui' solves all the problems. But it's a step in the right 
direction where USE flags actually start meaning something and not resembling 
the Ubuntu 'apt-get install libgtk+3 libfoo ...'
-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] [RFC] Global USE=gui

[Nick Vinson]

On 06/02/2016 08:08 AM, Raymond Jennings wrote:
> use case:  Telling a package to build a gui without deciding which one
> to build.  Also helps in cases where you have package A that can only
> build a qt gui, and package B that can build both qt and gtk, and
> package C that can build gtk only.  You want to have a gui for all
> three, but you don't want to hav epackage B build both guis and at the
> same time while you may prefer qt, you don't want to leave package C
> without a gui.

How do you decide which one package B builds in such a case?

Honestly, I don't think this is a good idea.  The rationale  and
suggested implementation just don't bring enough benefit in my opinion.
Often times it's hard enough to research a reported issue with the
current implementation.  Having a flag like 'gui' whose behavior
(potentially) changes based on what profile is being used makes things
considerably harder.  It would no longer be a simple matter of matching
versions and USE flags, the package maintainer would also need to setup
an equivalent system with the same profile or research what the 'gui'
flag with profile 'x' does and setup an equivalent USE flag set.

Gentoo already has Gnome, KDE, Plasma, and Desktop profiles which mostly
do the same thing.  The only thing they don't do (as I understand the
profiles) is enable GUI support for packages that don't support the
preferred libraries.  Is that really enough justification to implement
this flag?

As a maintainer I'd ask that, at the very least, a more compelling
reason than "it's too annoying to update package.use" is given.  I find
the argument against putting all the flags in global a valid but weak as
there are already mitigations for that scenario.   Perhaps I'm missing
something, but I'm not convinced this will provide a significant enough
benefit to the average Gentoo user to offset the increased
troubleshooting demand it'll put on Gentoo's developers, maintainers,
and proxy-maintainers.

Thanks,
Nicholas Vinson

P.S. I'd also like to add that I do spend a considerable amount of time
in #gentoo and I don't recall seeing this problem come up that much.
The closest I've seen was a user asking where /usr/bin/VirtualBox was
(as it only gets installed when the proper qt USE flag is set), but
based on personal experience that happens maybe 1 or 2 every 3 - 4
months (if that often).

> 
> On Thu, Jun 2, 2016 at 7:20 AM, Ian Stakenvicius  > wrote:
> 
> On 01/06/16 10:13 PM, waltd...@waltdnes.org
>  wrote:
> > On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
> >
> >> waltd...@waltdnes.org  wrote:
> >>
> >>>   I see this as at least a redundancy, if not a problem.  First, let's
> >>> look at the general case.  An optional "UI" (User Interface) is also
> >>> selected...
> >>> * via the "tools" useflag 78 times in use.local.desc
> >>> * via the "ncurses" useflag 10 times in use.local.desc.
> >>> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
> >>>   does "ncurses" show up in use.local.desc ???)
> >>>
> >>>  There is no need for an additional "TUI" (Text User Interface) use 
> flag
> >>> for these cases.  "tools" and/or "ncurses" tells you enough.  
> Similarly,
> >>> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
> >>> thing they have in common is a hard-coded dependancy on graphics libs.
> >>> "GUI" is an implicit dependancy of 
> gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
> >>> Using any of them tells you enough.  What do we accomplish by 
> requiring
> >>> one more USE flag?  This will also make dependancy resolution of 
> ebuilds
> >>> more complex, i.e. slower.  Why?
> >>
> >> Simple regular users don't want to be concerned with choice of toolkit
> >> for every single package, as long as a GUI is provided.
> >
> >   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
> > make.conf.  This will *FORCE* a gui where applicable.
> >
> 
> 
> The whole point of USE=gui is to get away from needing to do that.
> Those flags should be used to choose -which- gui toolkit users want
> when one is available, not to choose IF a gui should be built or not.
> Take my example into account, i don't want anything qt based if I can
> avoid it, but i definitely want wpa-gui.  Right now I only get wpa-gui
> if I enable USE=qt4 (or USE=qt5 presumably) on wpa_supplicant.  I'm
> not going to set that globally though because I don't want to choose
> qt4 based front-ends for anything else, and having to guess for every
> random package when i don't care so that I can set a package.use entry
> for it is annoying.
> 
> 
> >> Furthermore, this matches the recommended USE flag design where the
> >> more important flags are provided as feature flags, while 

Re: [gentoo-dev] [RFC] Global USE=gui

[Daniel Campbell]

On 06/02/2016 02:55 PM, Rich Freeman wrote:
> On Thu, Jun 2, 2016 at 5:27 PM, Daniel Campbell  wrote:
>> To play devil's advocate, can we get a citation on "users don't want to
>> care"? Which users? Does Gentoo have a lot of users who don't care, or
>> does it attract a more passionate audience that enjoys the control that
>> comes with being source-based? I'm inclined to believe the latter, but
>> I'm ready to be wrong.
>>
> 
> I'm willing to believe we have a lot of users who love micromanaging
> USE flags.  The day Gentoo requires this sort of behavior to work
> correctly is the day I won't be a user...  :)
> 
> Gentoo SHOULD give users choices.  It should also pick reasonable
> defaults when users opt not to specify a choice.
I agree. Sane defaults are what make system maintenance easy.

> 
> Obviously if a user just wants Ubuntu or Arch they should just install
> Ubuntu or Arch.  However, I think a common use case is going to be a
> user wants very fine-grained control over a particular aspect of their
> system, but they're not going to care about the rest.  Maybe a user
> does a lot of development in a particular language and they want
> fine-grained control over how their compiler/interpreter/etc works,
> but that doesn't mean that when they fire up a browser to check
> stackexchange that they want to tweak every setting.  Maybe somebody
> has a server used for media transcoding and they want to tweak all the
> ffmpeg/libav build options, but otherwise want a distro that just
> works as far as ssh/openrc/systemd and so on goes.
> 
> It would be one thing if we had to sacrifice the super-OCD users to
> cater to the non-OCD users.  However, I don't really see a reason why
> we can't service both.  This proposal works for either set of users.
> If a package doesn't give fine-grained control over libraries then the
> OCD users aren't really losing anything they had before.  If it does
> then USE=+gui gets the users who don't care their gui, and it still
> lets the people who want to tweak qt/gtk/etc the ability to do so.
> 
Well, that's the incoming problem when we accept USE="gui". I'm in favor
of the change in spirit, because who doesn't want a Gentoo that needs
less babysitting? However, the devil is in the details with what this
change leads to. Let's say we push the gui flag anyway. It is a good
idea, after all. Now how do we, as developers, deal with the
intricacies? There's adding +foo to IUSE, there's REQUIRED_USE, the
proposed USE_EXPAND (and a strange syntax added to clarify preference),
and pkg_pretend. All of these are possible solutions but *which*
solution most definitely will affect the "super-OCD" users. Ideally, we
should only need to tell these users where the new change goes, e.g.
"Don't set it in make.conf anymore, use p.use or p.env" or some other
thing. We need to make sure that there's only _one_ step needed for each
group. The "everyman" user can add USE="gui" and be done with it. The
picky user will need to set their preference in some other way, but it
should only be in one place instead of, say, two or three.

Let's use a concrete example here: x11-misc/spacefm. For another,
different example, net-p2p/transmission. The former supports two
versions of GTK, the latter accepts three (or more?) different toolkits,
in addition to ncurses which _might_ be considered a GUI to some. (It
seems that GTK2 support is no longer accepted; is that upstream decision
or maintainer's? But I digress...)

Currently, setting that preference ("Screw qt4 I want qt5" or "Screw
GTK3 I want 2!") usually requires either a global make.conf setup (which
some of us are against due to it meaning different things in different
packages), or adding a p.use entry for every piece of software that one
has an opinion on. Sometimes REQUIRED_USE necessitates negating the
other options. (I regret that spacefm does this, but I'm not changing it
until we have a real solution)

If the USE_EXPAND is used, we get the GUI variable in make.conf that can
then be used to hint ebuilds as to what the user finds acceptable. If
they love Qt5 on everything except that one program, then -gui_qt5 in
p.use for that one program would work, and make sense. Choice of toolkit
is usually a global decision, so the GUI USE sounds great, until we get
conflicts. We then have to figure out what the preferred way to resolve
that conflict. For example, let's say someone adds gtk2 and qt5 to their
GUI in make.conf. A particular ebuild supports both. Do we hack the
build system to make two versions of the program? Do we perform the same
option that they'd get if it was just USE="gui"? What will our DEPENDS
look like after enacting this change? We need an honest answer about
this, even if it's just "maintainer discretion" and/or "use pkg_pretend".

In short, I'm in support of this _idea_, but until we have some sort of
suggestion on how maintainers should implement this for their users,
we're going to get inconsistency between 

Re: [gentoo-dev] [RFC] Global USE=gui

[Rich Freeman]

On Thu, Jun 2, 2016 at 5:27 PM, Daniel Campbell  wrote:
> To play devil's advocate, can we get a citation on "users don't want to
> care"? Which users? Does Gentoo have a lot of users who don't care, or
> does it attract a more passionate audience that enjoys the control that
> comes with being source-based? I'm inclined to believe the latter, but
> I'm ready to be wrong.
>

I'm willing to believe we have a lot of users who love micromanaging
USE flags.  The day Gentoo requires this sort of behavior to work
correctly is the day I won't be a user...  :)

Gentoo SHOULD give users choices.  It should also pick reasonable
defaults when users opt not to specify a choice.

Obviously if a user just wants Ubuntu or Arch they should just install
Ubuntu or Arch.  However, I think a common use case is going to be a
user wants very fine-grained control over a particular aspect of their
system, but they're not going to care about the rest.  Maybe a user
does a lot of development in a particular language and they want
fine-grained control over how their compiler/interpreter/etc works,
but that doesn't mean that when they fire up a browser to check
stackexchange that they want to tweak every setting.  Maybe somebody
has a server used for media transcoding and they want to tweak all the
ffmpeg/libav build options, but otherwise want a distro that just
works as far as ssh/openrc/systemd and so on goes.

It would be one thing if we had to sacrifice the super-OCD users to
cater to the non-OCD users.  However, I don't really see a reason why
we can't service both.  This proposal works for either set of users.
If a package doesn't give fine-grained control over libraries then the
OCD users aren't really losing anything they had before.  If it does
then USE=+gui gets the users who don't care their gui, and it still
lets the people who want to tweak qt/gtk/etc the ability to do so.

-- 
Rich

Re: [gentoo-dev] [RFC] Global USE=gui

[Daniel Campbell]

On 06/02/2016 01:46 PM, Michał Górny wrote:
> On Thu, 2 Jun 2016 16:37:58 -0400
> waltd...@waltdnes.org wrote:
> 
>> On Thu, Jun 02, 2016 at 04:25:07PM -0400, Ian Stakenvicius wrote
>>> On 02/06/16 03:42 PM, waltd...@waltdnes.org wrote:  
 On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote  
>
> IMHO, you see this in reverse. the 'gui' useflag would be useful for 
> users who don't want to care about X/wayland/mir and do not want to care 
> about gtk/qt, they just want windows to be drawn for the applications 
> they install -- without, if possible, pulling useless dependencies.  

   How, exactly, will the app draw windows without linking against one of
 X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
 pike?
   
>>>
>>> The "useless dependencies" is the result of one or more of these
>>> random flags being enabled globally when an end-user just wants to
>>> make sure they get the GUI built for their apps.  
>>
>>   The original discussion was about global defaults.  If you want
>> per-app settings, package.use is your friend.
> 
> I'm going to keep this short: please try to understand that not
> everyone can spend hours of time adjusting every single package
> in Gentoo so that it may finally start working as expected.
> 
> We understand that some people have goals like 'I want Qt everywhere,
> I hate GTK+ so much I'd rather not be able to do anything than have
> GTK+ on my system'. We respect them. But we're no longer going to
> optimize Gentoo for those people.
> 
Who are you speaking for with "we"?

The Gentoo GNOME team? Upstream GNOME? Some employer who's hiring
someone to introduce these flags to Gentoo? Outspoken users who have
(strangely) only spoken to a few developers with their concerns?

The council's not voted on this issue, so you're definitely not speaking
for all of us.

(Note I'm not necessarily against this USE flag deal, but we shouldn't
be speaking for anyone but ourselves here.)
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Rich Freeman]

On Thu, Jun 2, 2016 at 5:20 PM, Igor Savlook  wrote:
> Ok if i want just disable gtk i use USE="-gtk -gtk2 -gtk3".
>

And that is fine if your goal is to disable gtk.  Most people don't
have goals like this - their goal is probably to prefer qt, not to
disable gtk, and so on.  If you prefer a package with no gui to a
package with a gtk gui then what you proposed is the way to go about
it.

-- 
Rich

Re: [gentoo-dev] [RFC] Global USE=gui

[Daniel Campbell]

On 06/02/2016 12:57 PM, Damien Levac wrote:
> 
> 
> On 2016-06-02 03:42 PM, waltd...@waltdnes.org wrote:
>> On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote
>>> IMHO, you see this in reverse. the 'gui' useflag would be useful for
>>> users who don't want to care about X/wayland/mir and do not want to care
>>> about gtk/qt, they just want windows to be drawn for the applications
>>> they install -- without, if possible, pulling useless dependencies.
>>How, exactly, will the app draw windows without linking against one of
>> X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
>> pike?
> It will be linked to one of those, but the users don't want to care so
> reasonable default would apply.
> 
> For example, if I have setup my profile to be 'plasma', then having
> 'gui' in my global use flags would mean "build with qt5 support to
> provide my gui whenever possible, if not possible, fallback to whatever
> is available at the discretion of the package maintainer".
> 
> 2 nice properties I foresee this feature will have:
> 
> * If you do not like it, don't use it. It shouldn't affect any user
> unless they explicitly use the flag.
> * Negating the flag would mean to not build any GUI (i.e. headless
> server) which is cleaner than: '-qt3support -qt4 -qt5 -gtk -gtk3 -X
> -waylang...'
> 
> I do not think the question is whether the flag would be useful: it
> will. The question is: can it be implemented efficiently...
> 
> 
To play devil's advocate, can we get a citation on "users don't want to
care"? Which users? Does Gentoo have a lot of users who don't care, or
does it attract a more passionate audience that enjoys the control that
comes with being source-based? I'm inclined to believe the latter, but
I'm ready to be wrong.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Rich Freeman]

On Thu, Jun 2, 2016 at 4:46 PM, Michał Górny  wrote:
>
> We understand that some people have goals like 'I want Qt everywhere,
> I hate GTK+ so much I'd rather not be able to do anything than have
> GTK+ on my system'. We respect them. But we're no longer going to
> optimize Gentoo for those people.
>

++

I think this is the right direction to take.  Packages should try to
use the appropriate libraries by default (assuming they support more
than one), so the plasma user gets apps linked to qt5, and so on.  The
user shouldn't have to set USE flags to get basic behavior like this -
maybe they just pick a profile.

If a plasma user installs a package that only supports gtk, then it
pulls in gtk.

Users shouldn't need a laundry list of global or per-package USE
settings if they don't really care which libraries they need.  This
reasonable default behavior also shouldn't result in every single
package pulling in every possible optional dependency as well.  It
should just use the "right" one.

If somebody wants to set USE=-* and micromanage every package, well,
that will always work on Gentoo.  However, that should not be the use
case we optimize for.

-- 
Rich

Re: [gentoo-dev] [RFC] Global USE=gui

[Igor Savlook]

On 06/02/16 23:46, Michał Górny wrote:

On Thu, 2 Jun 2016 16:37:58 -0400
waltd...@waltdnes.org wrote:


On Thu, Jun 02, 2016 at 04:25:07PM -0400, Ian Stakenvicius wrote

On 02/06/16 03:42 PM, waltd...@waltdnes.org wrote:

On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote


IMHO, you see this in reverse. the 'gui' useflag would be useful for
users who don't want to care about X/wayland/mir and do not want to care
about gtk/qt, they just want windows to be drawn for the applications
they install -- without, if possible, pulling useless dependencies.


   How, exactly, will the app draw windows without linking against one of
X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
pike?



The "useless dependencies" is the result of one or more of these
random flags being enabled globally when an end-user just wants to
make sure they get the GUI built for their apps.


   The original discussion was about global defaults.  If you want
per-app settings, package.use is your friend.


I'm going to keep this short: please try to understand that not
everyone can spend hours of time adjusting every single package
in Gentoo so that it may finally start working as expected.

We understand that some people have goals like 'I want Qt everywhere,
I hate GTK+ so much I'd rather not be able to do anything than have
GTK+ on my system'. We respect them. But we're no longer going to
optimize Gentoo for those people.


Ok if i want just disable gtk i use USE="-gtk -gtk2 -gtk3".

Re: [gentoo-dev] [RFC] Global USE=gui

[Michał Górny]

On Thu, 2 Jun 2016 16:37:58 -0400
waltd...@waltdnes.org wrote:

> On Thu, Jun 02, 2016 at 04:25:07PM -0400, Ian Stakenvicius wrote
> > On 02/06/16 03:42 PM, waltd...@waltdnes.org wrote:  
> > > On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote  
> > >>
> > >> IMHO, you see this in reverse. the 'gui' useflag would be useful for 
> > >> users who don't want to care about X/wayland/mir and do not want to care 
> > >> about gtk/qt, they just want windows to be drawn for the applications 
> > >> they install -- without, if possible, pulling useless dependencies.  
> > > 
> > >   How, exactly, will the app draw windows without linking against one of
> > > X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
> > > pike?
> > >   
> > 
> > The "useless dependencies" is the result of one or more of these
> > random flags being enabled globally when an end-user just wants to
> > make sure they get the GUI built for their apps.  
> 
>   The original discussion was about global defaults.  If you want
> per-app settings, package.use is your friend.

I'm going to keep this short: please try to understand that not
everyone can spend hours of time adjusting every single package
in Gentoo so that it may finally start working as expected.

We understand that some people have goals like 'I want Qt everywhere,
I hate GTK+ so much I'd rather not be able to do anything than have
GTK+ on my system'. We respect them. But we're no longer going to
optimize Gentoo for those people.

-- 
Best regards,
Michał Górny



pgpURU0KLB1wz.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Thu, Jun 02, 2016 at 04:25:07PM -0400, Ian Stakenvicius wrote
> On 02/06/16 03:42 PM, waltd...@waltdnes.org wrote:
> > On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote
> >>
> >> IMHO, you see this in reverse. the 'gui' useflag would be useful for 
> >> users who don't want to care about X/wayland/mir and do not want to care 
> >> about gtk/qt, they just want windows to be drawn for the applications 
> >> they install -- without, if possible, pulling useless dependencies.
> > 
> >   How, exactly, will the app draw windows without linking against one of
> > X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
> > pike?
> > 
> 
> The "useless dependencies" is the result of one or more of these
> random flags being enabled globally when an end-user just wants to
> make sure they get the GUI built for their apps.

  The original discussion was about global defaults.  If you want
per-app settings, package.use is your friend.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 02/06/16 03:42 PM, waltd...@waltdnes.org wrote:
> On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote
>>
>> IMHO, you see this in reverse. the 'gui' useflag would be useful for 
>> users who don't want to care about X/wayland/mir and do not want to care 
>> about gtk/qt, they just want windows to be drawn for the applications 
>> they install -- without, if possible, pulling useless dependencies.
> 
>   How, exactly, will the app draw windows without linking against one of
> X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
> pike?
> 

The "useless dependencies" is the result of one or more of these
random flags being enabled globally when an end-user just wants to
make sure they get the GUI built for their apps.







signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Damien Levac]

On 2016-06-02 03:42 PM, waltd...@waltdnes.org wrote:

On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote

IMHO, you see this in reverse. the 'gui' useflag would be useful for
users who don't want to care about X/wayland/mir and do not want to care
about gtk/qt, they just want windows to be drawn for the applications
they install -- without, if possible, pulling useless dependencies.

   How, exactly, will the app draw windows without linking against one of
X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
pike?
It will be linked to one of those, but the users don't want to care so 
reasonable default would apply.


For example, if I have setup my profile to be 'plasma', then having 
'gui' in my global use flags would mean "build with qt5 support to 
provide my gui whenever possible, if not possible, fallback to whatever 
is available at the discretion of the package maintainer".


2 nice properties I foresee this feature will have:

* If you do not like it, don't use it. It shouldn't affect any user 
unless they explicitly use the flag.
* Negating the flag would mean to not build any GUI (i.e. headless 
server) which is cleaner than: '-qt3support -qt4 -qt5 -gtk -gtk3 -X 
-waylang...'


I do not think the question is whether the flag would be useful: it 
will. The question is: can it be implemented efficiently...

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote
> 
> IMHO, you see this in reverse. the 'gui' useflag would be useful for 
> users who don't want to care about X/wayland/mir and do not want to care 
> about gtk/qt, they just want windows to be drawn for the applications 
> they install -- without, if possible, pulling useless dependencies.

  How, exactly, will the app draw windows without linking against one of
X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
pike?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Thu, Jun 02, 2016 at 06:50:59AM +0100, Graham Murray wrote
> waltd...@waltdnes.org writes:
> 
> >   Let me re-phrase my question... is there *ANY* set of circumstances
> > under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> > can be set for a package *WITHOUT* requiring a gui?
> 
> Yes. X/xorg could be needed to incorporate the X Client libraries so
> that X servers can connect to it but not itself have a gui. This
> could, for example, be on a headless server.

  Is it broken right now?  What improvement will we see from having to
add a "GUI" flag?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Global USE=gui

[Raymond Jennings]

use case:  Telling a package to build a gui without deciding which one to
build.  Also helps in cases where you have package A that can only build a
qt gui, and package B that can build both qt and gtk, and package C that
can build gtk only.  You want to have a gui for all three, but you don't
want to hav epackage B build both guis and at the same time while you may
prefer qt, you don't want to leave package C without a gui.

On Thu, Jun 2, 2016 at 7:20 AM, Ian Stakenvicius  wrote:

> On 01/06/16 10:13 PM, waltd...@waltdnes.org wrote:
> > On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
> >
> >> waltd...@waltdnes.org wrote:
> >>
> >>>   I see this as at least a redundancy, if not a problem.  First, let's
> >>> look at the general case.  An optional "UI" (User Interface) is also
> >>> selected...
> >>> * via the "tools" useflag 78 times in use.local.desc
> >>> * via the "ncurses" useflag 10 times in use.local.desc.
> >>> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
> >>>   does "ncurses" show up in use.local.desc ???)
> >>>
> >>>  There is no need for an additional "TUI" (Text User Interface) use
> flag
> >>> for these cases.  "tools" and/or "ncurses" tells you enough.
> Similarly,
> >>> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
> >>> thing they have in common is a hard-coded dependancy on graphics libs.
> >>> "GUI" is an implicit dependancy of
> gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
> >>> Using any of them tells you enough.  What do we accomplish by requiring
> >>> one more USE flag?  This will also make dependancy resolution of
> ebuilds
> >>> more complex, i.e. slower.  Why?
> >>
> >> Simple regular users don't want to be concerned with choice of toolkit
> >> for every single package, as long as a GUI is provided.
> >
> >   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
> > make.conf.  This will *FORCE* a gui where applicable.
> >
>
>
> The whole point of USE=gui is to get away from needing to do that.
> Those flags should be used to choose -which- gui toolkit users want
> when one is available, not to choose IF a gui should be built or not.
> Take my example into account, i don't want anything qt based if I can
> avoid it, but i definitely want wpa-gui.  Right now I only get wpa-gui
> if I enable USE=qt4 (or USE=qt5 presumably) on wpa_supplicant.  I'm
> not going to set that globally though because I don't want to choose
> qt4 based front-ends for anything else, and having to guess for every
> random package when i don't care so that I can set a package.use entry
> for it is annoying.
>
>
> >> Furthermore, this matches the recommended USE flag design where the
> >> more important flags are provided as feature flags, while specific
> >> dependency choice flags are minor.
> >
> >   This is going to require *THREE* levels of flags, with the first one
> > being totally unnecessary...
> >
> > Level 1) GUI
> >
> > Level 2) X or xorg or Wayland or Mir
> >
> > Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk
>
>
> 1 - USE=gui is for optional gui-or-no-gui, so yes in this scheme its
> needed.
>
> 2 - If X or Wayland or Mir support is available in a package, then yes
> -- also i don't see a way that we don't need these.
>
> 3 - toolkit selection choices when a package supports multiple (but
> only chooses one) is also a yes.  AND, because we're not tying any-gui
> to one of these flags it means that users are free to set just the one
> variant that they prefer, globally, instead of having to mess about
> per-package.  It also means we can get rid of any or all of these
> particular flags from profiles (except for 'gnome' or 'plasma' or the
> desktop-variant-specific ones).
>
> The point here is that if there's an app (say, wpa_supplicant as
> mentioned before) that provides a gui tool but no options as to what
> that tool needs in terms of toolkit etc, we can -just- have USE=gui
> control whether or not it's built.  It'll pull in qt because qt is
> what it needs, and if someone is dead set against having qt in their
> system then they'll know from the dependency tree.  There's no need to
> peg the individual toolkit to packages like this just to enable a gui.
>
>
> >
> >   Let me re-phrase my question... is there *ANY* set of circumstances
> > under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> > can be set for a package *WITHOUT* requiring a gui?  I can see any of X
> > or xorg or Wayland or Mir being a requirement for any of
> > qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
> > a GUI of one sort or another.
>
>
> Likely there is but I'd need to search.  Extending libraries mostly --
> cairo, pango etc.. for X vs no-X, avahi for gtk*/qt* ...
>
>
>
>
>

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 01/06/16 10:13 PM, waltd...@waltdnes.org wrote:
> On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
> 
>> waltd...@waltdnes.org wrote:
>>
>>>   I see this as at least a redundancy, if not a problem.  First, let's
>>> look at the general case.  An optional "UI" (User Interface) is also
>>> selected...
>>> * via the "tools" useflag 78 times in use.local.desc
>>> * via the "ncurses" useflag 10 times in use.local.desc.
>>> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
>>>   does "ncurses" show up in use.local.desc ???)
>>>
>>>  There is no need for an additional "TUI" (Text User Interface) use flag
>>> for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
>>> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
>>> thing they have in common is a hard-coded dependancy on graphics libs.
>>> "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
>>> Using any of them tells you enough.  What do we accomplish by requiring
>>> one more USE flag?  This will also make dependancy resolution of ebuilds
>>> more complex, i.e. slower.  Why?
>>
>> Simple regular users don't want to be concerned with choice of toolkit
>> for every single package, as long as a GUI is provided.
> 
>   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
> make.conf.  This will *FORCE* a gui where applicable.
> 


The whole point of USE=gui is to get away from needing to do that.
Those flags should be used to choose -which- gui toolkit users want
when one is available, not to choose IF a gui should be built or not.
Take my example into account, i don't want anything qt based if I can
avoid it, but i definitely want wpa-gui.  Right now I only get wpa-gui
if I enable USE=qt4 (or USE=qt5 presumably) on wpa_supplicant.  I'm
not going to set that globally though because I don't want to choose
qt4 based front-ends for anything else, and having to guess for every
random package when i don't care so that I can set a package.use entry
for it is annoying.


>> Furthermore, this matches the recommended USE flag design where the
>> more important flags are provided as feature flags, while specific
>> dependency choice flags are minor.
> 
>   This is going to require *THREE* levels of flags, with the first one
> being totally unnecessary...
> 
> Level 1) GUI
> 
> Level 2) X or xorg or Wayland or Mir
> 
> Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk


1 - USE=gui is for optional gui-or-no-gui, so yes in this scheme its
needed.

2 - If X or Wayland or Mir support is available in a package, then yes
-- also i don't see a way that we don't need these.

3 - toolkit selection choices when a package supports multiple (but
only chooses one) is also a yes.  AND, because we're not tying any-gui
to one of these flags it means that users are free to set just the one
variant that they prefer, globally, instead of having to mess about
per-package.  It also means we can get rid of any or all of these
particular flags from profiles (except for 'gnome' or 'plasma' or the
desktop-variant-specific ones).

The point here is that if there's an app (say, wpa_supplicant as
mentioned before) that provides a gui tool but no options as to what
that tool needs in terms of toolkit etc, we can -just- have USE=gui
control whether or not it's built.  It'll pull in qt because qt is
what it needs, and if someone is dead set against having qt in their
system then they'll know from the dependency tree.  There's no need to
peg the individual toolkit to packages like this just to enable a gui.


> 
>   Let me re-phrase my question... is there *ANY* set of circumstances
> under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> can be set for a package *WITHOUT* requiring a gui?  I can see any of X
> or xorg or Wayland or Mir being a requirement for any of
> qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
> a GUI of one sort or another.


Likely there is but I'd need to search.  Extending libraries mostly --
cairo, pango etc.. for X vs no-X, avahi for gtk*/qt* ...






signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Damien Levac]

On 2016-06-01 10:13 PM, waltd...@waltdnes.org wrote:

On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote


waltd...@waltdnes.org wrote:


   I see this as at least a redundancy, if not a problem.  First, let's
look at the general case.  An optional "UI" (User Interface) is also
selected...
* via the "tools" useflag 78 times in use.local.desc
* via the "ncurses" useflag 10 times in use.local.desc.
* for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
   does "ncurses" show up in use.local.desc ???)

  There is no need for an additional "TUI" (Text User Interface) use flag
for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
"GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
thing they have in common is a hard-coded dependancy on graphics libs.
"GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
Using any of them tells you enough.  What do we accomplish by requiring
one more USE flag?  This will also make dependancy resolution of ebuilds
more complex, i.e. slower.  Why?

Simple regular users don't want to be concerned with choice of toolkit
for every single package, as long as a GUI is provided.

   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
make.conf.  This will *FORCE* a gui where applicable.


Furthermore, this matches the recommended USE flag design where the
more important flags are provided as feature flags, while specific
dependency choice flags are minor.

   This is going to require *THREE* levels of flags, with the first one
being totally unnecessary...

Level 1) GUI

Level 2) X or xorg or Wayland or Mir

Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk
   Let me re-phrase my question... is there *ANY* set of circumstances
under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
can be set for a package *WITHOUT* requiring a gui?  I can see any of X
or xorg or Wayland or Mir being a requirement for any of
qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
a GUI of one sort or another.
IMHO, you see this in reverse. the 'gui' useflag would be useful for 
users who don't want to care about X/wayland/mir and do not want to care 
about gtk/qt, they just want windows to be drawn for the applications 
they install -- without, if possible, pulling useless dependencies.


   I repeat, requiring a "GUI" use flag for GUI apps makes as much sense
as requiring a "TUI" flag for commandline apps.  I hope I'm not giving
people ideas the wrong way.  No I don't want a "TUI" flag either.

Re: [gentoo-dev] [RFC] Global USE=gui

[Graham Murray]

waltd...@waltdnes.org writes:

>   Let me re-phrase my question... is there *ANY* set of circumstances
> under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> can be set for a package *WITHOUT* requiring a gui?

Yes. X/xorg could be needed to incorporate the X Client libraries so
that X servers can connect to it but not itself have a gui. This
could, for example, be on a headless server.

Re: [gentoo-dev] [RFC] Global USE=gui

[Michał Górny]

On Wed, 1 Jun 2016 22:13:24 -0400
waltd...@waltdnes.org wrote:

> On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
> 
> > waltd...@waltdnes.org wrote:
> >   
> > >   I see this as at least a redundancy, if not a problem.  First, let's
> > > look at the general case.  An optional "UI" (User Interface) is also
> > > selected...
> > > * via the "tools" useflag 78 times in use.local.desc
> > > * via the "ncurses" useflag 10 times in use.local.desc.
> > > * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
> > >   does "ncurses" show up in use.local.desc ???)
> > > 
> > >  There is no need for an additional "TUI" (Text User Interface) use flag
> > > for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
> > > "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
> > > thing they have in common is a hard-coded dependancy on graphics libs.
> > > "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
> > > Using any of them tells you enough.  What do we accomplish by requiring
> > > one more USE flag?  This will also make dependancy resolution of ebuilds
> > > more complex, i.e. slower.  Why?  
> > 
> > Simple regular users don't want to be concerned with choice of toolkit
> > for every single package, as long as a GUI is provided.  
> 
>   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
> make.conf.  This will *FORCE* a gui where applicable.

And also a dozen random things, and USE flag conflicts where multiple
GUIs are applicable.

> > Furthermore, this matches the recommended USE flag design where the
> > more important flags are provided as feature flags, while specific
> > dependency choice flags are minor.  
> 
>   This is going to require *THREE* levels of flags, with the first one
> being totally unnecessary...
> 
> Level 1) GUI
> 
> Level 2) X or xorg or Wayland or Mir
> 
> Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk
> 
>   Let me re-phrase my question... is there *ANY* set of circumstances
> under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> can be set for a package *WITHOUT* requiring a gui?  I can see any of X
> or xorg or Wayland or Mir being a requirement for any of
> qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
> a GUI of one sort or another.
> 
>   I repeat, requiring a "GUI" use flag for GUI apps makes as much sense
> as requiring a "TUI" flag for commandline apps.  I hope I'm not giving
> people ideas the wrong way.  No I don't want a "TUI" flag either.

That's your opinion, and that is how far it goes as I'm concerned. Next
thing you complain, that USE=ssl doesn't mean 'openssl only'.

-- 
Best regards,
Michał Górny



pgpFuac7FNZbF.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote

> waltd...@waltdnes.org wrote:
> 
> >   I see this as at least a redundancy, if not a problem.  First, let's
> > look at the general case.  An optional "UI" (User Interface) is also
> > selected...
> > * via the "tools" useflag 78 times in use.local.desc
> > * via the "ncurses" useflag 10 times in use.local.desc.
> > * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
> >   does "ncurses" show up in use.local.desc ???)
> > 
> >  There is no need for an additional "TUI" (Text User Interface) use flag
> > for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
> > "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
> > thing they have in common is a hard-coded dependancy on graphics libs.
> > "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
> > Using any of them tells you enough.  What do we accomplish by requiring
> > one more USE flag?  This will also make dependancy resolution of ebuilds
> > more complex, i.e. slower.  Why?
> 
> Simple regular users don't want to be concerned with choice of toolkit
> for every single package, as long as a GUI is provided.

  Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
make.conf.  This will *FORCE* a gui where applicable.

> Furthermore, this matches the recommended USE flag design where the
> more important flags are provided as feature flags, while specific
> dependency choice flags are minor.

  This is going to require *THREE* levels of flags, with the first one
being totally unnecessary...

Level 1) GUI

Level 2) X or xorg or Wayland or Mir

Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk

  Let me re-phrase my question... is there *ANY* set of circumstances
under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
can be set for a package *WITHOUT* requiring a gui?  I can see any of X
or xorg or Wayland or Mir being a requirement for any of
qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
a GUI of one sort or another.

  I repeat, requiring a "GUI" use flag for GUI apps makes as much sense
as requiring a "TUI" flag for commandline apps.  I hope I'm not giving
people ideas the wrong way.  No I don't want a "TUI" flag either.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Global USE=gui

[Michał Górny]

On Wed, 1 Jun 2016 13:53:31 -0400
waltd...@waltdnes.org wrote:

> On Wed, Jun 01, 2016 at 05:29:55PM +0300, Mart Raudsepp wrote
> 
> > It is meant as a feature based USE flag, as opposed to the "extra dep"
> > based USE flags we've been using for this.
> > There are a lot of those with USE=gtk right now. In many cases it's
> > some little add-on graphical utility for a library, or some graphical
> > configuration GUI in addition to command line, or some bigger cases in
> > more modular packages that provide multiple frontends, and not all of
> > them are graphical, but CLI or TUI (TUI meaning ncurses-based or
> > similar).
> > Also there are various with USE=X where it's also about that, but X
> > isn't the only way to do GUI these days (any gtk3 app that doesn't
> > directly use libX11/libxcb/etc themselves natively supports wayland,
> > for example).
> > 
> > Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
> > of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
> > available in only one toolkit version. So hence feature based flag, not
> > dependency-based.  
> 
>   I see this as at least a redundancy, if not a problem.  First, let's
> look at the general case.  An optional "UI" (User Interface) is also
> selected...
> * via the "tools" useflag 78 times in use.local.desc
> * via the "ncurses" useflag 10 times in use.local.desc.
> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
>   does "ncurses" show up in use.local.desc ???)
> 
>  There is no need for an additional "TUI" (Text User Interface) use flag
> for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
> thing they have in common is a hard-coded dependancy on graphics libs.
> "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
> Using any of them tells you enough.  What do we accomplish by requiring
> one more USE flag?  This will also make dependancy resolution of ebuilds
> more complex, i.e. slower.  Why?

Simple regular users don't want to be concerned with choice of toolkit
for every single package, as long as a GUI is provided. Furthermore,
this matches the recommended USE flag design where the more important
flags are provided as feature flags, while specific dependency choice
flags are minor.

-- 
Best regards,
Michał Górny



pgpZYEKJPjs1O.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Wed, Jun 01, 2016 at 05:29:55PM +0300, Mart Raudsepp wrote

> It is meant as a feature based USE flag, as opposed to the "extra dep"
> based USE flags we've been using for this.
> There are a lot of those with USE=gtk right now. In many cases it's
> some little add-on graphical utility for a library, or some graphical
> configuration GUI in addition to command line, or some bigger cases in
> more modular packages that provide multiple frontends, and not all of
> them are graphical, but CLI or TUI (TUI meaning ncurses-based or
> similar).
> Also there are various with USE=X where it's also about that, but X
> isn't the only way to do GUI these days (any gtk3 app that doesn't
> directly use libX11/libxcb/etc themselves natively supports wayland,
> for example).
> 
> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
> available in only one toolkit version. So hence feature based flag, not
> dependency-based.

  I see this as at least a redundancy, if not a problem.  First, let's
look at the general case.  An optional "UI" (User Interface) is also
selected...
* via the "tools" useflag 78 times in use.local.desc
* via the "ncurses" useflag 10 times in use.local.desc.
* for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
  does "ncurses" show up in use.local.desc ???)

 There is no need for an additional "TUI" (Text User Interface) use flag
for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
"GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
thing they have in common is a hard-coded dependancy on graphics libs.
"GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
Using any of them tells you enough.  What do we accomplish by requiring
one more USE flag?  This will also make dependancy resolution of ebuilds
more complex, i.e. slower.  Why?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Global USE=gui

[Raymond Jennings]

What about a global "default gui" somewhere in make.conf that says what GUI
to use if a package provides multiple?

Relatedly, I also like having a general "qt" USE flag to select any/the
best version of qt, and then having "qtX' for each version of qt...ditto
for gtk and gtkX

On Wed, Jun 1, 2016 at 9:59 AM, NP-Hardass  wrote:

> On 06/01/2016 12:52 PM, Ian Stakenvicius wrote:
> > On 01/06/16 11:19 AM, NP-Hardass wrote:
> >> On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
> >>> Hello,
> >>>
> >>> So here's something more simple wrt GUI USE flags.
> >>>
> >>> Global USE=gui for
> >>> gui - enable an optional graphics user interface or extra GUI tool
> >>>
> >>> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
> >>> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
> >>> available in only one toolkit version. So hence feature based flag, not
> >>> dependency-based.
> >>>
> >> I know that it was previously mentioned that there was discussion about
> >> this long ago, but I'm not familiar with those discussions. Is someone
> >> more familiar with those discussions able to bring up the talking
> points?
> >>
> >> One issue that springs to mind though is, let's say a pkg supports only
> >> qt4 for a gui, you'd have the gui flag. Upstream adds qt5 support.  Do
> >> you keep the gui flag and make qt4 and qt5 dependent on it, or do you
> >> remove the gui flag?  I feel like the latter might lead to confusion,
> >> while the former suggests that the flag should be used more generally
> >> than just one toolkit/version being available.
> >
> > This would be the:
> >
> >>> There are some other things in the ideas pipeline for when there are
> >>> multiple toolkit choices, but that's something for a different thread,
> >>> a different day and more controversial.
> >
> > ...portion. :)
> >
> >
> Ah :)
>
> --
> NP-Hardass
>
>

Re: [gentoo-dev] [RFC] Global USE=gui

[NP-Hardass]

On 06/01/2016 12:52 PM, Ian Stakenvicius wrote:
> On 01/06/16 11:19 AM, NP-Hardass wrote:
>> On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
>>> Hello,
>>>
>>> So here's something more simple wrt GUI USE flags.
>>>
>>> Global USE=gui for
>>> gui - enable an optional graphics user interface or extra GUI tool
>>>
>>> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
>>> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
>>> available in only one toolkit version. So hence feature based flag, not
>>> dependency-based.
>>>
>> I know that it was previously mentioned that there was discussion about
>> this long ago, but I'm not familiar with those discussions. Is someone
>> more familiar with those discussions able to bring up the talking points?
>>
>> One issue that springs to mind though is, let's say a pkg supports only
>> qt4 for a gui, you'd have the gui flag. Upstream adds qt5 support.  Do
>> you keep the gui flag and make qt4 and qt5 dependent on it, or do you
>> remove the gui flag?  I feel like the latter might lead to confusion,
>> while the former suggests that the flag should be used more generally
>> than just one toolkit/version being available.
> 
> This would be the:
> 
>>> There are some other things in the ideas pipeline for when there are
>>> multiple toolkit choices, but that's something for a different thread,
>>> a different day and more controversial.
> 
> ...portion. :)
> 
> 
Ah :)

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Daniel Campbell]

On 06/01/2016 09:21 AM, Michał Górny wrote:
> On Wed, 01 Jun 2016 17:29:55 +0300
> Mart Raudsepp  wrote:
> 
>> Hello,
>>
>> So here's something more simple wrt GUI USE flags.
>>
>> Global USE=gui for
>> gui - enable an optional graphics user interface or extra GUI tool
>>
>> (wording improvements welcome, once it's in principle agreed; but no
>> point in bikeshed painting description wording till it is)
> 
> How about:
> 
> gui - Enable an optional graphics user interface. If multiple variants
> of the GUI are available, additional flags may provide a more
> fine-grained choice of them.
> 
Pretty much nailed it as far as I'm concerned.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 01/06/16 11:19 AM, NP-Hardass wrote:
> On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
>> Hello,
>>
>> So here's something more simple wrt GUI USE flags.
>>
>> Global USE=gui for
>> gui - enable an optional graphics user interface or extra GUI tool
>>
>> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
>> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
>> available in only one toolkit version. So hence feature based flag, not
>> dependency-based.
>>
> I know that it was previously mentioned that there was discussion about
> this long ago, but I'm not familiar with those discussions. Is someone
> more familiar with those discussions able to bring up the talking points?
> 
> One issue that springs to mind though is, let's say a pkg supports only
> qt4 for a gui, you'd have the gui flag. Upstream adds qt5 support.  Do
> you keep the gui flag and make qt4 and qt5 dependent on it, or do you
> remove the gui flag?  I feel like the latter might lead to confusion,
> while the former suggests that the flag should be used more generally
> than just one toolkit/version being available.

This would be the:

>> There are some other things in the ideas pipeline for when there are
>> multiple toolkit choices, but that's something for a different thread,
>> a different day and more controversial.

...portion. :)




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[NP-Hardass]

On 06/01/2016 12:21 PM, Michał Górny wrote:
> On Wed, 01 Jun 2016 17:29:55 +0300
> Mart Raudsepp  wrote:
> 
>> Hello,
>>
>> So here's something more simple wrt GUI USE flags.
>>
>> Global USE=gui for
>> gui - enable an optional graphics user interface or extra GUI tool
>>
>> (wording improvements welcome, once it's in principle agreed; but no
>> point in bikeshed painting description wording till it is)
> 
> How about:
> 
> gui - Enable an optional graphics user interface. If multiple variants
> of the GUI are available, additional flags may provide a more
> fine-grained choice of them.
> 
This resolves the question in my previous post.  So, if using the
premise that it'd apply for all gui selection, and specific gui
libs/flags are dependent on the gui flag via REQUIRED_USE or another
means, then that SGTM.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Michał Górny]

On Wed, 01 Jun 2016 17:29:55 +0300
Mart Raudsepp  wrote:

> Hello,
> 
> So here's something more simple wrt GUI USE flags.
> 
> Global USE=gui for
> gui - enable an optional graphics user interface or extra GUI tool
> 
> (wording improvements welcome, once it's in principle agreed; but no
> point in bikeshed painting description wording till it is)

How about:

gui - Enable an optional graphics user interface. If multiple variants
of the GUI are available, additional flags may provide a more
fine-grained choice of them.

-- 
Best regards,
Michał Górny



pgpmCt3ALI8eZ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Daniel Campbell (zlg)]

On June 1, 2016 7:29:55 AM PDT, Mart Raudsepp  wrote:
>Hello,
>
>So here's something more simple wrt GUI USE flags.
>
>Global USE=gui for
>gui - enable an optional graphics user interface or extra GUI tool
>
>(wording improvements welcome, once it's in principle agreed; but no
>point in bikeshed painting description wording till it is)
>
>Local USE flag description overrides to specify exactly what extra tool
>is built and installed with the flag are encouraged.
>
>
>This is meant to cover the cases where a package has an optional GUI,
>as a user facing graphical application, whichever the toolkit.
>
>It is meant as a feature based USE flag, as opposed to the "extra dep"
>based USE flags we've been using for this.
>There are a lot of those with USE=gtk right now. In many cases it's
>some little add-on graphical utility for a library, or some graphical
>configuration GUI in addition to command line, or some bigger cases in
>more modular packages that provide multiple frontends, and not all of
>them are graphical, but CLI or TUI (TUI meaning ncurses-based or
>similar).
>Also there are various with USE=X where it's also about that, but X
>isn't the only way to do GUI these days (any gtk3 app that doesn't
>directly use libX11/libxcb/etc themselves natively supports wayland,
>for example).
>
>Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
>of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
>available in only one toolkit version. So hence feature based flag, not
>dependency-based.
>
>http://tinyurl.com/gtk-use was an old analysis of USE=gtk usage in tree
>by Gilles over a year ago. That suggests that at least 80+ USE flags
>should be then USE=gui instead of USE=gtk out of that analyzed USE=gtk
>subset alone, not counting USE=X and others.
>
>There are some other things in the ideas pipeline for when there are
>multiple toolkit choices, but that's something for a different thread,
>a different day and more controversial.
>
>
>Mart

This idea is solid imo, but only in the case where there's a single (optional) 
GUI to use. We've discussed the finer points of this on IRC and, as you noted, 
the specifics need some more input and refinement, but in essence I like and 
support this idea.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] [RFC] Global USE=gui

[Damien Levac]

On 2016-06-01 11:19 AM, NP-Hardass wrote:

On 06/01/2016 10:29 AM, Mart Raudsepp wrote:

Hello,

So here's something more simple wrt GUI USE flags.

Global USE=gui for
gui - enable an optional graphics user interface or extra GUI tool

Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
available in only one toolkit version. So hence feature based flag, not
dependency-based.


I know that it was previously mentioned that there was discussion about
this long ago, but I'm not familiar with those discussions. Is someone
more familiar with those discussions able to bring up the talking points?

One issue that springs to mind though is, let's say a pkg supports only
qt4 for a gui, you'd have the gui flag. Upstream adds qt5 support.  Do
you keep the gui flag and make qt4 and qt5 dependent on it, or do you
remove the gui flag?
The way I understand it, the 'gui' flag guarantees a GUI to be built, 
not which one. I assume it would default to upstream recommendation or 
the gentoo dev's judgement.

I feel like the latter might lead to confusion,
while the former suggests that the flag should be used more generally
than just one toolkit/version being available.

Mart

Re: [gentoo-dev] [RFC] Global USE=gui

[NP-Hardass]

On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
> Hello,
> 
> So here's something more simple wrt GUI USE flags.
> 
> Global USE=gui for
> gui - enable an optional graphics user interface or extra GUI tool
> 
> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
> available in only one toolkit version. So hence feature based flag, not
> dependency-based.
> 
I know that it was previously mentioned that there was discussion about
this long ago, but I'm not familiar with those discussions. Is someone
more familiar with those discussions able to bring up the talking points?

One issue that springs to mind though is, let's say a pkg supports only
qt4 for a gui, you'd have the gui flag. Upstream adds qt5 support.  Do
you keep the gui flag and make qt4 and qt5 dependent on it, or do you
remove the gui flag?  I feel like the latter might lead to confusion,
while the former suggests that the flag should be used more generally
than just one toolkit/version being available.
> 
> Mart
> 

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [RFC] Global USE=gui

[Mart Raudsepp]

Hello,

So here's something more simple wrt GUI USE flags.

Global USE=gui for
gui - enable an optional graphics user interface or extra GUI tool

(wording improvements welcome, once it's in principle agreed; but no
point in bikeshed painting description wording till it is)

Local USE flag description overrides to specify exactly what extra tool
is built and installed with the flag are encouraged.


This is meant to cover the cases where a package has an optional GUI,
as a user facing graphical application, whichever the toolkit.

It is meant as a feature based USE flag, as opposed to the "extra dep"
based USE flags we've been using for this.
There are a lot of those with USE=gtk right now. In many cases it's
some little add-on graphical utility for a library, or some graphical
configuration GUI in addition to command line, or some bigger cases in
more modular packages that provide multiple frontends, and not all of
them are graphical, but CLI or TUI (TUI meaning ncurses-based or
similar).
Also there are various with USE=X where it's also about that, but X
isn't the only way to do GUI these days (any gtk3 app that doesn't
directly use libX11/libxcb/etc themselves natively supports wayland,
for example).

Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
available in only one toolkit version. So hence feature based flag, not
dependency-based.

http://tinyurl.com/gtk-use was an old analysis of USE=gtk usage in tree
by Gilles over a year ago. That suggests that at least 80+ USE flags
should be then USE=gui instead of USE=gtk out of that analyzed USE=gtk
subset alone, not counting USE=X and others.

There are some other things in the ideas pipeline for when there are
multiple toolkit choices, but that's something for a different thread,
a different day and more controversial.


Mart