Re: [gentoo-dev] www-client/chromium gtk3 support

[Vadim A. Misbakh-Soloviov]

> <...> 
> I'm sorry, I wrote too briefly. hasufell seems to be saying that gtk2
> should be deprecated now. I'm just agreeing with Rich that if upstream
> supports both *and* the maintainer wants to support both, there's no
> reason to force them to only support one.
> <...>
> As Rich has mentioned already, if upstream thinks they support gtk2 but
> it crashes when using gtk2, I am perfectly fine with the maintainer
> closing the bug as WONTFIX because upstream broke things.

I absolutelly double that. That is the point which I evangelizing above.

hasufell's statement about gtk2 looks like  statement that we 
should drop "that your eudev, and, better, openrc too" and force users to move 
to SysD. Which would be a crime against Gentoo Philosophy.

But, as usual, there is a sidenote: as you remember, we've dropped Qt3/KDE3 
packages over the time (I remeber how I've upgraded to KDE4 about 7 years ago 
and there was situation, similar to current gtk2-3 one. And just right now 
there is another similar situation happening around Qt4-5). There is point to 
do such thing when upstream drop that support. Only. Also, there is a point to 
drop gtk2-only packages later, when upstreams will die. Until that, such 
proposiions looks like tyranny.

-- 
Best regards,
mva


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Vadim A. Misbakh-Soloviov]

> And its absolutely OK for a maintainer to close the bug as WONTFIX after a
> lively discussion.

Absolutelly yes. And it is users right to go and make that theyself (either in 
overlay or by proxymaint).

The key of mystatement was in that NOBODY in Gentoo can (at least, should not 
have the power to be able to) dictate which features mainainers (which is most 
of the time are users of maintained packages) should maintain, and which they 
shall exclude. Maximum censorship is about ebuilds coding quality. But nobody 
ever should try to dictate "we should drop baselayout, because of systemd", 
"we should drop one toolkit becouse of another", and so on.

-- 
Best regards,
mva


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Rich Freeman]

On Sat, Sep 12, 2015 at 12:55 AM, Raymond Jennings  wrote:
> On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman  wrote:
>>
>> On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell  wrote:
>> >
>> > I like the general 'gtk' flag we generally use to choose *which*
>> > toolkit, and local USE flags for specific versions, if they are
>> > supported. But in that case, the general gtk flag should be
>> > interpreted as the latest version supported, so users don't come
>> > across weirdly behaving packages that default to gtk2 (unless that
>> > version is the most stable).
>> >
>> >...
>> >
>> > For starters, versioned USE flags more than likely don't belong in
>> > make.conf's USE variable and shouldn't be global.
>
> Personally i disagree with this.
>
> Versioned use flags for widely used dependencies (like a windowing toolkit)
> IMO qualify as global USE flags because they have a common effect across
> many packages.

He wasn't suggesting that they have different meanings for different
packages.  By saying that they shouldn't be global he meant that users
should not typically be manipulating them at a global level, such as
in make.conf.

Back in the day it was common to stick flags like these in make.conf
or in profiles, since if you didn't packages wouldn't build GUIs and
such.  That was before USE defaults and it caused a lot of headaches
when multiple versions of toolkits started coming along and setting
these flags started causing harm.

But, the way we use the terms local/global USE flags is confusing.
They can mean that a flag has a package-specific vs global meaning, or
the terms can mean that it is recommended that the flag be enabled at
the package.use level vs at the make.conf level.  To be fair to you,
until very recently the first meaning was the most common.  People are
talking more about the second meaning of late because of problems that
happen when people try to tweak fairly detailed settings like gtk3 at
the global level.

>
>> I'd be tempted to even say to not have gtk3 but instead call the flag
>> chromium-gtk3 or whatever so that it becomes very difficult to put in
>> the global config.  However, that goes against our general principle
>> of letting the user break their system and keep the pieces if they
>> think they know what they're doing.  If somebody WANTS to test out a
>> gtk3-only system or whatever they should have the freedom to do so,
>> understanding that testing sometimes uncovers problems.
>
> I actually also think that there should be a single USE flag for building on
> gtk3, called gtk3.  calling it "(packagename)-gtk3" is a bit redundant, and
> also flies in the face of having a single global flag with a coherent
> purpose.
>

The only reason for doing it the other way would be to make it harder
for users to shoot themselves in the foot by setting these flags in
make.conf.  They'd have to put 50 flags in make.conf and not just one.
However, in general Gentoo operates under the principle that while we
should avoid surprising the user, we shouldn't actually make it hard
for the user to override our decisions when they feel it is best.

-- 
Rich

Re: [gentoo-dev] www-client/chromium gtk3 support

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/10/2015 11:26 AM, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 2:21 PM, hasufell 
> wrote:
>> On 09/10/2015 08:15 PM, Daniel Campbell wrote:
>>> 
>>> tldr: If the problem is USE flags, let's talk USE flags. If
>>> it's supporting more than one toolkit in general, I see no
>>> reason not to let maintainers use their discretion and not
>>> force their hand in either direction.
>>> 
>> 
>> We have provided several arguments here repeatedly.
>> 
> 
> Well, right now the status quo is that this is up to maintainers. 
> There is no policy that states otherwise.
> 
> The USE flag issue is on the next council agenda, though I'm not 
> really confident that we'll resolve it in one go - there are only
> a few days before the meeting.  If anybody has concerns about the 
> approach that we take I'd suggest posting them on the thread, but
> I suspect that most likely the council will go around the circle
> and assess where everybody generally stands, then propose something
> more solid for a vote the following meeting (which gives everybody
> an opportunity to shoot holes it in beforehand).
> 

Honestly, I can understand where the gnome team is coming from wrt
keeping things moving forward. I personally don't think highly of
gtk3, but in the grand scheme of things, if that's where it's going,
maybe we *should* establish some policy on how USE flags are named
and/or used. Use cases do indeed differ; sometimes it enables an
optional GUI, sometimes it's one of many toolkit options. Whatever
decision is made I'm fine with so long as I can ensure users of
packages I maintain can choose which toolkit the package is built with
(assuming upstream supports it, of course).

I like the general 'gtk' flag we generally use to choose *which*
toolkit, and local USE flags for specific versions, if they are
supported. But in that case, the general gtk flag should be
interpreted as the latest version supported, so users don't come
across weirdly behaving packages that default to gtk2 (unless that
version is the most stable).

It's hard to apply such standards across a tree of thousands of
packages, each with their own upstreams, build systems, code
standards, and so on. I'm sure there's something we can find that
enables us to continue providing choice to users while maintaining
some semblance of consistency across the tree.

For starters, versioned USE flags more than likely don't belong in
make.conf's USE variable and shouldn't be global.

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

iQIcBAEBCAAGBQJV8pjLAAoJEAEkDpRQOeFwu04P/0Hypny+iEXfEnvzl5MAVb+y
OdpUYwhuhDq79cK5DEbs0sfc9deTYWj8PL8FOpxrSnunT6hwwesMepXQDWFInRhE
aF9tvTgZJG7NlW6D4vG6d2+sOluuYXqkv75vezf173k/02WD8FxVlD3dbeIOrItn
IH7JiBfJNzyXLgF9bjzxxV5ANe37jWf8j5ZGfvlv/NEiasM8zsDJzC0MQeEnPy6/
RNgjvP9U+BtWxHwLjgib6F4aYIr5aZzwa7bgbP7JGN88RPgui53LgklZjsxLh1sG
qXnFmInejE2gNPt2yO5yxahue2tABCKiSFiZcYyhDMyA3vW+c4Uu71szlB2iWsWG
ZeDG1FY5SR4nreD/Er/q5GQPuU/B32FzuJpc+e7F5uzBGVY+ZuHX9UJnFb6KFwg/
hxDXiVwJLoMHEMIfqk6NRI0A44aLDqJamND9Hv3D97jC1kLnu56qzhMVj+8/SQkn
bXPtBQJEybMIemmobtm7clnjtY2wbFo4paN269+gJkgHoKmA+FpCCDX2eBFvCl/G
yNkFEFwXp0SN4XaUQ3LysBlh3BZcb1grUeJKxt5punf9T6/Cc16V5jzjD7e2o/3g
rD/oL5ea/BEyB2QPFII7IJl8V9kjAnVSPtGhvn8UJNtLUbS3tZEtwXONwDLNQV0R
AD8GxhNJBRgau84x55na
=v5ss
-END PGP SIGNATURE-

Re: [gentoo-dev] www-client/chromium gtk3 support

[Raymond Jennings]

On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman  wrote:

> On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell  wrote:
> >
> > I like the general 'gtk' flag we generally use to choose *which*
> > toolkit, and local USE flags for specific versions, if they are
> > supported. But in that case, the general gtk flag should be
> > interpreted as the latest version supported, so users don't come
> > across weirdly behaving packages that default to gtk2 (unless that
> > version is the most stable).
> >
> >...
> >
> > For starters, versioned USE flags more than likely don't belong in
> > make.conf's USE variable and shouldn't be global.
>

Personally i disagree with this.

Versioned use flags for widely used dependencies (like a windowing toolkit)
IMO qualify as global USE flags because they have a common effect across
many packages.

That was roughly my proposal.
>
> USE=gui or something like that if the main effect is to have a gui or
> not.  That is the sort of thing that SHOULD go in make.conf or in a
> profile.  If disabling gtk makes it a console-only application then
> use the gui flag.
>
> USE=gtk if the main effect is to select /which/ toolkit is used if
> more than one is optionally supported.  That /might/ go in a make.conf
> or profile, but probably shouldn't in general.  It is more appropriate
> for something like the desktop/gnome profile than the desktop profile.
>
> USE=gtk# if you're picking which version to use.  That should /almost
> never/ go in a profile (unless you're talking about a testing profile
> of some kind, such as on an overlay), or in a global config unless you
> REALLY know what you're getting into.  Users setting this globally
> should expect to run into bugs.  The package should default these
> flags to whatever is most appropriate for the specific package.
>

I really like this approach, and I think that having tiers of
(gui)->(qt/gtk)->(qt4/qt5//gtk2/gtk3) would go a long way to keeping USE
flags coherent.

I'd be tempted to even say to not have gtk3 but instead call the flag
> chromium-gtk3 or whatever so that it becomes very difficult to put in
> the global config.  However, that goes against our general principle
> of letting the user break their system and keep the pieces if they
> think they know what they're doing.  If somebody WANTS to test out a
> gtk3-only system or whatever they should have the freedom to do so,
> understanding that testing sometimes uncovers problems.
>

I actually also think that there should be a single USE flag for building
on gtk3, called gtk3.  calling it "(packagename)-gtk3" is a bit redundant,
and also flies in the face of having a single global flag with a coherent
purpose.

Of course any change will need a transition period, news, handbook
> updates, etc.  For the person who wants the "just works" experience
> they can pick a profile and it will do the right thing, and if they
> want to tailor things a bit more the USE=(-)gui flag will do what it
> would be expected to do.
>
> --
> Rich
>
>

Re: [gentoo-dev] www-client/chromium gtk3 support

[Rich Freeman]

On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell  wrote:
>
> I like the general 'gtk' flag we generally use to choose *which*
> toolkit, and local USE flags for specific versions, if they are
> supported. But in that case, the general gtk flag should be
> interpreted as the latest version supported, so users don't come
> across weirdly behaving packages that default to gtk2 (unless that
> version is the most stable).
>
>...
>
> For starters, versioned USE flags more than likely don't belong in
> make.conf's USE variable and shouldn't be global.
>

That was roughly my proposal.

USE=gui or something like that if the main effect is to have a gui or
not.  That is the sort of thing that SHOULD go in make.conf or in a
profile.  If disabling gtk makes it a console-only application then
use the gui flag.

USE=gtk if the main effect is to select /which/ toolkit is used if
more than one is optionally supported.  That /might/ go in a make.conf
or profile, but probably shouldn't in general.  It is more appropriate
for something like the desktop/gnome profile than the desktop profile.

USE=gtk# if you're picking which version to use.  That should /almost
never/ go in a profile (unless you're talking about a testing profile
of some kind, such as on an overlay), or in a global config unless you
REALLY know what you're getting into.  Users setting this globally
should expect to run into bugs.  The package should default these
flags to whatever is most appropriate for the specific package.

I'd be tempted to even say to not have gtk3 but instead call the flag
chromium-gtk3 or whatever so that it becomes very difficult to put in
the global config.  However, that goes against our general principle
of letting the user break their system and keep the pieces if they
think they know what they're doing.  If somebody WANTS to test out a
gtk3-only system or whatever they should have the freedom to do so,
understanding that testing sometimes uncovers problems.

Of course any change will need a transition period, news, handbook
updates, etc.  For the person who wants the "just works" experience
they can pick a profile and it will do the right thing, and if they
want to tailor things a bit more the USE=(-)gui flag will do what it
would be expected to do.

-- 
Rich

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/10/2015 08:21 AM, Daniel Campbell wrote:
> 
> For me to not support gtk2 in the spacefm ebuild would be providing a
> package inferior to upstream.

That sounds like spacefm with gtk3 is lacking anything. It is not.
Providing choice for the sake of choice is not always a good idea.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Rich Freeman]

On Thu, Sep 10, 2015 at 8:13 AM, hasufell  wrote:
> On 09/10/2015 02:03 PM, Rich Freeman wrote:
>>
>> Suppose you want to run on a non-embedded system with limited RAM and the
>> ability to choose means you can use one of the two libraries
>> exclusively, thus eliminating the need to load the other library?
>> Being able to control what libraries are in use is a key feature of
>> Gentoo, IMO.
>>
>
> Any reference that gtk3 has a higher memory footprint?
>

gtk2+gtk3 in RAM at the same time has a higher memory footprint than
either one alone.  If any package uses one or the other, it will end
up being loaded into RAM, so there is potentially value in using one
of them exclusively.

I'm not suggesting that package maintainers should be forced to
support both whenever possible.  I just don't think they should be
discouraged from doing so.

-- 
Rich

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/10/2015 02:25 PM, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 8:13 AM, hasufell  wrote:
>> On 09/10/2015 02:03 PM, Rich Freeman wrote:
>>>
>>> Suppose you want to run on a non-embedded system with limited RAM and the
>>> ability to choose means you can use one of the two libraries
>>> exclusively, thus eliminating the need to load the other library?
>>> Being able to control what libraries are in use is a key feature of
>>> Gentoo, IMO.
>>>
>>
>> Any reference that gtk3 has a higher memory footprint?
>>
> 
> gtk2+gtk3 in RAM at the same time has a higher memory footprint than
> either one alone.  If any package uses one or the other, it will end
> up being loaded into RAM, so there is potentially value in using one
> of them exclusively.
> 

So you are saying for the unlikely case that someone runs gentoo on a
desktop system where he cannot even compile gcc, llvm and others without
waiting for 2 weeks or setting up his on binhost, we have to provide a
backup-path for him, so that gtk3 is not loaded into his RAM?

Do you know what that means if you want to _actually_ (not just
theoretically) support that? You have to do that consistently, not just
for a few packages.

So this makes no sense, since it's already an unsupported corner case.

> I'm not suggesting that package maintainers should be forced to
> support both whenever possible.  I just don't think they should be
> discouraged from doing so.
> 

Yes, they should be discouraged. It's a QA matter.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Michał Górny]

Dnia 2015-09-10, o godz. 08:46:41
Alec Ten Harmsel  napisał(a):

> If upstream gives the option of gtk2 or gtk3, why shouldn't the ebuild?
> From the "I want a usable system with as little code as possible" and "I
> want a system tailored to my needs" standpoints, having only one version
> of gtk makes quite a bit of sense.

This is the same case as with many other libraries which suffered major
API changes -- SDL, for example. Just because upstream *thinks* they
support two GTK+ versions, doesn't mean they do. Only one of the
versions is well-tested, and the second one sometimes isn't tested at
all, neither by upstream nor by the developer.

The happy end result is, sometimes user has choice between 'working
package' and 'package randomly segfaulting when you least expect it'.
Of course, it's all hidden nicely under USE=gtk2 and USE=gtk3, so just
*maybe* if you have the time to read local flag descriptions for every
single package you may notice which of the flags should be enabled to
get a working app.

But yes, wasting people's time and offering easy way to data loss is
better than not supporting some imaginary corner case when you can
actually use some fancy combination of applications that can actually
run without that one library without losing stability and benefit you.

I hope you are ready to pay the developers who will waste their time
figuring out what goes wrong when you report a bug, until they figure
out it's because you have forced GTK+ version which upstream thought
they're supporting but they do not. That's certainly a better
alternative than paying for hardware that can handle loading two
libraries.

-- 
Best regards,
Michał Górny



pgph8vxwswJ68.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] www-client/chromium gtk3 support

[Rich Freeman]

On Thu, Sep 10, 2015 at 6:50 AM, hasufell  wrote:
> On 09/10/2015 12:45 PM, Rich Freeman wrote:
>> On Thu, Sep 10, 2015 at 4:47 AM, hasufell  wrote:
>>> On 09/10/2015 08:21 AM, Daniel Campbell wrote:

 For me to not support gtk2 in the spacefm ebuild would be providing a
 package inferior to upstream.
>>>
>>> That sounds like spacefm with gtk3 is lacking anything. It is not.
>>> Providing choice for the sake of choice is not always a good idea.
>>>
>>
>> Suppose you want to run on an embedded system with limited RAM and the
>> ability to choose means you can use one of the two libraries
>> exclusively, thus eliminating the need to load the other library?
>> Being able to control what libraries are in use is a key feature of
>> Gentoo, IMO.
>>
>
> We are not optimizing GUI desktop systems for embedded systems . That's
> totally unrealistic and not a real use case.
>

Suppose you want to run on a non-embedded system with limited RAM and the
ability to choose means you can use one of the two libraries
exclusively, thus eliminating the need to load the other library?
Being able to control what libraries are in use is a key feature of
Gentoo, IMO.

-- 
Rich

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/10/2015 02:44 PM, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 8:33 AM, hasufell  wrote:
>>
>> So this makes no sense, since it's already an unsupported corner case.
> 
> Just what use of Gentoo do you not consider an unsupported corner
> case, which isn't already better supported by some other distro?
> 
> The whole point of using Gentoo is having "support" for all those
> "unsupported corner cases."  If you just want everything to support
> doing things in the one way which is most supportable, you're
> basically doing a really bad job at re-inventing Debian.
> 
> I use quotes around support since all support on Gentoo is
> best-effort, and that is all I'm getting at here.  If a package
> maintainer can support multiple configurations and are willing to do
> so, they should be encouraged to do so.
> 

So we are breaking consistency and introduce maintenance and
configuration complexity, because we want to support a corner case that
isn't consistently supported anyway and will not be (because that's what
the gnome team said and most upstream maintainers do).

You'd actually have to start forking upstream projects if you are
serious about this. Everything else is just fighting the deprecation,
which will come anyway.

I think a lot of people just go wild when they see configure switches
and stuff everything into USE flags without really considering the
impact or the usefulness.

It's not all about choice, it's also about sanity.

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/10/2015 12:45 PM, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 4:47 AM, hasufell  wrote:
>> On 09/10/2015 08:21 AM, Daniel Campbell wrote:
>>>
>>> For me to not support gtk2 in the spacefm ebuild would be providing a
>>> package inferior to upstream.
>>
>> That sounds like spacefm with gtk3 is lacking anything. It is not.
>> Providing choice for the sake of choice is not always a good idea.
>>
> 
> Suppose you want to run on an embedded system with limited RAM and the
> ability to choose means you can use one of the two libraries
> exclusively, thus eliminating the need to load the other library?
> Being able to control what libraries are in use is a key feature of
> Gentoo, IMO.
> 

We are not optimizing GUI desktop systems for embedded systems . That's
totally unrealistic and not a real use case.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Rich Freeman]

On Thu, Sep 10, 2015 at 8:33 AM, hasufell  wrote:
>
> So this makes no sense, since it's already an unsupported corner case.

Just what use of Gentoo do you not consider an unsupported corner
case, which isn't already better supported by some other distro?

The whole point of using Gentoo is having "support" for all those
"unsupported corner cases."  If you just want everything to support
doing things in the one way which is most supportable, you're
basically doing a really bad job at re-inventing Debian.

I use quotes around support since all support on Gentoo is
best-effort, and that is all I'm getting at here.  If a package
maintainer can support multiple configurations and are willing to do
so, they should be encouraged to do so.

>
>> I'm not suggesting that package maintainers should be forced to
>> support both whenever possible.  I just don't think they should be
>> discouraged from doing so.
>>
>
> Yes, they should be discouraged. It's a QA matter.
>

Well, I'm glad we've all aired our opinions on the matter.  :)

I just fail to see the QA issue here, unless it again boils down to
that it is easier to do QA when you have one configuration (like
Debian) and not many (like Gentoo).

The other issue that keeps coming up is that we don't have good
standards for USE flag naming in these situations, and the solution to
that is to come up with a good uniform practice.

-- 
Rich

Re: [gentoo-dev] www-client/chromium gtk3 support

[Rich Freeman]

On Thu, Sep 10, 2015 at 9:07 AM, Michał Górny  wrote:
>
> The happy end result is, sometimes user has choice between 'working
> package' and 'package randomly segfaulting when you least expect it'.
> Of course, it's all hidden nicely under USE=gtk2 and USE=gtk3, so just
> *maybe* if you have the time to read local flag descriptions for every
> single package you may notice which of the flags should be enabled to
> get a working app.

I'd propose that anybody sticking USE=gtk2 or USE=gtk3 in their USE
flags should expect to have a less-supportable system.  The problem
isn't the fact that the library is configurable, but rather that we
don't provide users an easy way to just install the package in the
best-supported configuration with a GUI.  Users shouldn't have to read
all the local descriptions to figure out how to install a package -
there should be a reasonable default that does what they want.  That
doesn't necessitate only supporting a single toolkit version.

This is on the agenda for discussion at the next council meeting, and
has been the subject of numerous threads in various contexts.  I think
the biggest problem here is that everybody does things a little
differently.  That, and we know a lot more than we did back when devs
were first adding these kinds of versioned flags.

>
> I hope you are ready to pay the developers who will waste their time
> figuring out what goes wrong when you report a bug, until they figure
> out it's because you have forced GTK+ version which upstream thought
> they're supporting but they do not. That's certainly a better
> alternative than paying for hardware that can handle loading two
> libraries.

Again, I'm suggesting this should be up to maintainer's discretion.
If they choose to support two gtk versions, and upstream chooses to do
the same, then why should we worry about filing bugs against a version
they chose to support?  If they don't want to support two versions,
they shouldn't.

This seems a bit like arguing that we shouldn't have
package-I-don't-use in the tree because the dev effort required to
support it could be better spent on package-I-use which isn't in the
tree.  That sounds nice, but I don't get to dictate what people spend
their time on, and the most we can do from a policy standpoint is
forbid contribution, not force contribution.

-- 
Rich

Re: [gentoo-dev] www-client/chromium gtk3 support

[Rich Freeman]

On Thu, Sep 10, 2015 at 4:47 AM, hasufell  wrote:
> On 09/10/2015 08:21 AM, Daniel Campbell wrote:
>>
>> For me to not support gtk2 in the spacefm ebuild would be providing a
>> package inferior to upstream.
>
> That sounds like spacefm with gtk3 is lacking anything. It is not.
> Providing choice for the sake of choice is not always a good idea.
>

Suppose you want to run on an embedded system with limited RAM and the
ability to choose means you can use one of the two libraries
exclusively, thus eliminating the need to load the other library?
Being able to control what libraries are in use is a key feature of
Gentoo, IMO.

-- 
Rich

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/10/2015 02:03 PM, Rich Freeman wrote:
> 
> Suppose you want to run on a non-embedded system with limited RAM and the
> ability to choose means you can use one of the two libraries
> exclusively, thus eliminating the need to load the other library?
> Being able to control what libraries are in use is a key feature of
> Gentoo, IMO.
> 

Any reference that gtk3 has a higher memory footprint?

Re: [gentoo-dev] www-client/chromium gtk3 support

[Michael Orlitzky]

On 09/10/2015 08:33 AM, hasufell wrote:
> 
> So you are saying for the unlikely case that someone runs gentoo on a
> desktop system where he cannot even compile gcc, llvm and others without
> waiting for 2 weeks or setting up his on binhost, we have to provide a
> backup-path for him, so that gtk3 is not loaded into his RAM?
> 

My only laptop runs Gentoo and is ten years old. The CPU is decent but
there's not much RAM and what I do have is shared with the video card. I
don't pay attention to gtk2/gtk3 on it, but it's not hard to imagine
someone would care.

(I can compile GCC just fine in under an hour, you just can't do
anything else at the same time because the whole things locks up and
heats to roughly the temperature of the sun.)

Re: [gentoo-dev] www-client/chromium gtk3 support

[Alec Ten Harmsel]

On Thu, Sep 10, 2015 at 02:33:09PM +0200, hasufell wrote:
> On 09/10/2015 02:25 PM, Rich Freeman wrote:
> >
> > gtk2+gtk3 in RAM at the same time has a higher memory footprint than
> > either one alone.  If any package uses one or the other, it will end
> > up being loaded into RAM, so there is potentially value in using one
> > of them exclusively.
> >
>
> So you are saying for the unlikely case that someone runs gentoo on a
> desktop system where he cannot even compile gcc, llvm and others without
> waiting for 2 weeks or setting up his on binhost, we have to provide a
> backup-path for him, so that gtk3 is not loaded into his RAM?

That was my situation until very recently. Firefox builds took ~6 hours.
gcc took 2-3 hours. Even though gtk is not that big, it still took 15ish
minutes for me to build.

If upstream gives the option of gtk2 or gtk3, why shouldn't the ebuild?
>From the "I want a usable system with as little code as possible" and "I
want a system tailored to my needs" standpoints, having only one version
of gtk makes quite a bit of sense.

Alec

Re: [gentoo-dev] www-client/chromium gtk3 support

[Rich Freeman]

On Thu, Sep 10, 2015 at 8:53 AM, hasufell  wrote:
>
> So we are breaking consistency and introduce maintenance and
> configuration complexity, because we want to support a corner case that
> isn't consistently supported anyway and will not be (because that's what
> the gnome team said and most upstream maintainers do).
>
> You'd actually have to start forking upstream projects if you are
> serious about this.

Again, I'm saying that maintainers should be free to support multiple
versions if they wish to do so.  They should not be required to do so.
And yes, I do realize that this limits options for users, but they're
welcome to proxy-maintain packages that do support the versions they
wish to use.  If they want to fork upstream they're even welcome to do
that, but obviously that isn't going to happen often.

I just don't think we should be in the business of saying "no" here.

>
> I think a lot of people just go wild when they see configure switches
> and stuff everything into USE flags without really considering the
> impact or the usefulness.
>
> It's not all about choice, it's also about sanity.
>

And again, I'm just saying to leave it up to the maintainer.  They can
decide what is sane and what is not.

That is basically how we do everything around here.  I can't really
think of that many situations where a maintainer wanted to provide
some kind of configuration and they were forbidden from doing so.
Now, sometimes we might tell them /how/ to provide that configuration
so that it is more consistent across the tree, or so that build
behavior is more deterministic/etc.

> Everything else is just fighting the deprecation,
> which will come anyway.

Everything we do is fighting deprecation.  gtk3 will be deprecated
someday, most likely, and yet we're doing all this work to roll it
out.

Maintainers should be free to add value to Gentoo when they feel it is
worth their time to do so.  That is basically how we got to where we
are today.  Gentoo supports all kinds of stuff that I think is
intellectually interesting but which I'd probably not use personally,
but I'm happy to see it happening all the same and I'm happy that it
is scratching somebody's itch.  At the same time, I use Gentoo
features that were added because they scratched somebody else's itch,
even if they weren't thinking about me personally when they did it.

-- 
Rich

Re: [gentoo-dev] www-client/chromium gtk3 support

[Alan McKinnon]

On 10/09/2015 14:44, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 8:33 AM, hasufell  wrote:
>>
>> So this makes no sense, since it's already an unsupported corner case.
> 
> Just what use of Gentoo do you not consider an unsupported corner
> case, which isn't already better supported by some other distro?
> 
> The whole point of using Gentoo is having "support" for all those
> "unsupported corner cases."  If you just want everything to support
> doing things in the one way which is most supportable, you're
> basically doing a really bad job at re-inventing Debian.
> 
> I use quotes around support since all support on Gentoo is
> best-effort, and that is all I'm getting at here.  If a package
> maintainer can support multiple configurations and are willing to do
> so, they should be encouraged to do so.
> 
>>
>>> I'm not suggesting that package maintainers should be forced to
>>> support both whenever possible.  I just don't think they should be
>>> discouraged from doing so.

+1

I'm fully with Rich here. gtk+2 is out there, it's in the tree and stuff
uses it. Therefore a way must exist for stuff to get to use it.

Everything else is whinging and nattering.

>>>
>>
>> Yes, they should be discouraged. It's a QA matter.
>>
> 

Since when does QA devise policy?
QA never devises policy
QA enforces policy that by definition is devised elsewhere

> Well, I'm glad we've all aired our opinions on the matter.  :)
> 
> I just fail to see the QA issue here, unless it again boils down to
> that it is easier to do QA when you have one configuration (like
> Debian) and not many (like Gentoo).
> 
> The other issue that keeps coming up is that we don't have good
> standards for USE flag naming in these situations, and the solution to
> that is to come up with a good uniform practice.

Having gtk, gtk2 and gtk3 USE flags used inconsistently is a problem,
that is not being denied.

What is not a problem is a package that supports one or more toolkits,
offers various ways to implement that support, is supported upstream and
desired by users. That is a fact and as this is not Debian people need
to be willing to let people solve that problem in ways they see fit.
Citing "QA policy" as a way to avoid having to deal with murky real-life
corner cases is just flat out wrong. And those murky corner cases exist,
they always will and are the things that separate real life from
theoretical ideals.

gtk2 exists and is in use. I see no plans to deprecate it globally, so
those who take issue with ugly USE syntax really should learn to deal
with it, or propose a more elegant solution that still accomplishes what
other devs are trying to do.

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-dev] www-client/chromium gtk3 support

[Alec Warner]

On Thu, Sep 10, 2015 at 8:35 AM, hasufell  wrote:

> On 09/10/2015 03:10 PM, Rich Freeman wrote:
> > On Thu, Sep 10, 2015 at 8:53 AM, hasufell  wrote:
> >>
> >> So we are breaking consistency and introduce maintenance and
> >> configuration complexity, because we want to support a corner case that
> >> isn't consistently supported anyway and will not be (because that's what
> >> the gnome team said and most upstream maintainers do).
> >>
> >> You'd actually have to start forking upstream projects if you are
> >> serious about this.
> >
> > Again, I'm saying that maintainers should be free to support multiple
> > versions if they wish to do so.  They should not be required to do so.
> > And yes, I do realize that this limits options for users, but they're
> > welcome to proxy-maintain packages that do support the versions they
> > wish to use.  If they want to fork upstream they're even welcome to do
> > that, but obviously that isn't going to happen often.
> >
> > I just don't think we should be in the business of saying "no" here.
>
> Again, your proposed use case is
> 1) imaginary
> 2) currently impossible to support, because there are lots of
> applications which either force gtk3 in the ebuild or have only gtk3
> supported upstream. It will be pretty much impossible to not have gtk3
> installed or loaded into RAM, unless you don't use a DE in the first
> place and stick to terminals.
>
> >
> >>
> >> I think a lot of people just go wild when they see configure switches
> >> and stuff everything into USE flags without really considering the
> >> impact or the usefulness.
> >>
> >> It's not all about choice, it's also about sanity.
> >>
> >
> > And again, I'm just saying to leave it up to the maintainer.
>
> If this affects tree consistency and usability, then it is not just up
> to the maintainers.


There are lots of topics where I concede that QA has a point and can
utilize its influence; but 'consistency and usability' are not topics I
would normally expect them to impose on developers.

-A

Re: [gentoo-dev] www-client/chromium gtk3 support

[Vadim A. Misbakh-Soloviov]

I disagree witho you and hasufell.

It *IS* users destiny if they get some stabiity issues because of their 
decision to have gtk2-only or gtk3-only system.

Yes, they can paste bugs about improper toolkit support. Is it bad? Rules says 
it should be reported upstream. And all the time Gentoo exists that worked 
this way.

The whole point of Gentoo is to give user freedom of the choice. Freedom to 
decide every aspect that is possible to decide about. Freedom to use Gentoo 
exactly as they want, but not as "you don't need feature X, because I'm 
maintainer/QA and said that", like some DebUbuntu maintainers did with git or, 
say, ejabberd, some years ago. Any movements to the easy side of "we will not 
support feature X, despite upstream still support it, because feature Y is 
newer and shiny, and feature X can be less tested" is a big fat violation of 
Gentoo philosophy.

And I totally agree with Rich: it is maintainer decision, if they ready to 
support mutiple build variants or not. And if not — it is absolutelly lawful 
user's right to file a bug against a package, that it has support in upstream, 
but has not in the Gentoo.

WE HAVE NO RIGHT TO DICTATE users what they should use and what they should 
not. We are makers of kinda army swiss knife suite that give user possibility 
and instruments to make everything they want. And any tries to say "you shall 
use SystemD, but not sysV/openrc/upstart/whatever", or "you shall use gtk3 
only", or "you shall use Qt5 only", and so on — is a CRIME against Gentoo 
philosophy.

-- 
Best regards,
mva


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/10/2015 03:10 PM, Rich Freeman wrote:
> On Thu, Sep 10, 2015 at 8:53 AM, hasufell  wrote:
>>
>> So we are breaking consistency and introduce maintenance and
>> configuration complexity, because we want to support a corner case that
>> isn't consistently supported anyway and will not be (because that's what
>> the gnome team said and most upstream maintainers do).
>>
>> You'd actually have to start forking upstream projects if you are
>> serious about this.
> 
> Again, I'm saying that maintainers should be free to support multiple
> versions if they wish to do so.  They should not be required to do so.
> And yes, I do realize that this limits options for users, but they're
> welcome to proxy-maintain packages that do support the versions they
> wish to use.  If they want to fork upstream they're even welcome to do
> that, but obviously that isn't going to happen often.
> 
> I just don't think we should be in the business of saying "no" here.

Again, your proposed use case is
1) imaginary
2) currently impossible to support, because there are lots of
applications which either force gtk3 in the ebuild or have only gtk3
supported upstream. It will be pretty much impossible to not have gtk3
installed or loaded into RAM, unless you don't use a DE in the first
place and stick to terminals.

> 
>>
>> I think a lot of people just go wild when they see configure switches
>> and stuff everything into USE flags without really considering the
>> impact or the usefulness.
>>
>> It's not all about choice, it's also about sanity.
>>
> 
> And again, I'm just saying to leave it up to the maintainer.

If this affects tree consistency and usability, then it is not just up
to the maintainers.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Alec Warner]

On Thu, Sep 10, 2015 at 7:31 AM, Vadim A. Misbakh-Soloviov 
wrote:

> I disagree witho you and hasufell.
>
> It *IS* users destiny if they get some stabiity issues because of their
> decision to have gtk2-only or gtk3-only system.
>
> Yes, they can paste bugs about improper toolkit support. Is it bad? Rules
> says
> it should be reported upstream. And all the time Gentoo exists that worked
> this way.
>

I agree, and yet, I wholly disagree.

In the before times, the maintainers were often users. They maintained
packages and added support for non-standard configurations precisely
because they needed these configurations; they wanted them and they
experimented with them.

As the distro grew in size, in userbase, and in package count, you see this
experimentation shunted off into other areas.

1) Local overlays. Often if users need to do a thing, they can simply use
epatch_user or similar local over-rides to gain the functionality they
desire. Gentoo itself has a fair amount of tooling to make this easy; its
still way easier than doing it in other distros (the oft-mentioned Debian
for example...)

2) Published overlays. We have overlays, and layman, and often discovering
that someone else has added support for the customizations you want is
fairly straightforward. Of course, it could be easier. Of course, we could
put all ebuilds in one giant repository. Unfortunately with users comes
some standard of reliability. In the early days I don't think anyone
equated Gentoo with reliability. I think there is some higher standard now
as many organizations have built atop Gentoo and expect some level of
reliability (now whether this is a sane expectation is a separate
discussion..but I digress.)


>
> The whole point of Gentoo is to give user freedom of the choice. Freedom to
> decide every aspect that is possible to decide about. Freedom to use Gentoo
> exactly as they want, but not as "you don't need feature X, because I'm
> maintainer/QA and said that", like some DebUbuntu maintainers did with git
> or,
> say, ejabberd, some years ago. Any movements to the easy side of "we will
> not
> support feature X, despite upstream still support it, because feature Y is
> newer and shiny, and feature X can be less tested" is a big fat violation
> of
> Gentoo philosophy.
>

I absolutely refuse to allow this user-choice to be used as a stick to beat
maintainers into doing whatever users want. The maintainers are the ones
doing the work, and they get to choose. Many maintainers are sympathetic to
user choice (as you note, it is a component of the distro philosophy) and
many maintainers go out of their way to support user choice. But it is not
a cudgel.


>
> And I totally agree with Rich: it is maintainer decision, if they ready to
> support mutiple build variants or not. And if not — it is absolutelly
> lawful
> user's right to file a bug against a package, that it has support in
> upstream,
> but has not in the Gentoo.
>

And its absolutely OK for a maintainer to close the bug as WONTFIX after a
lively discussion.


>
> WE HAVE NO RIGHT TO DICTATE users what they should use and what they should
> not. We are makers of kinda army swiss knife suite that give user
> possibility
> and instruments to make everything they want. And any tries to say "you
> shall
> use SystemD, but not sysV/openrc/upstart/whatever", or "you shall use gtk3
> only", or "you shall use Qt5 only", and so on — is a CRIME against Gentoo
> philosophy.
>

> --
> Best regards,
> mva
>

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/10/2015 04:31 PM, Vadim A. Misbakh-Soloviov wrote:
> WE HAVE NO RIGHT TO DICTATE users what they should use and what they should 
> not.

You should really either reconsider your understanding of opensource or
start to pay me.

Gentoo is for the most part GPL-2 and you can fork, change and
redistribute it any way you want. We are not dictating anything.

Given the fact that we are short on manpower and that most part of the
linux ecosystem is moving towards gtk3... there has been no good
argument to support a toolkit version - that is (about to be) deprecated
- for exotic corner use cases that people tried to come up with in the
heat of the argument.

Gtk3 is not gnome3. Gtk3 is not systemd. Can we please be realistic now?

Re: [gentoo-dev] www-client/chromium gtk3 support

[Rich Freeman]

On Thu, Sep 10, 2015 at 12:57 PM, hasufell  wrote:
> On 09/10/2015 04:31 PM, Vadim A. Misbakh-Soloviov wrote:
>> WE HAVE NO RIGHT TO DICTATE users what they should use and what they should
>> not.
>
> You should really either reconsider your understanding of opensource or
> start to pay me.
>
> Gentoo is for the most part GPL-2 and you can fork, change and
> redistribute it any way you want. We are not dictating anything.

++

>
> Given the fact that we are short on manpower and that most part of the
> linux ecosystem is moving towards gtk3... there has been no good
> argument to support a toolkit version - that is (about to be) deprecated
> - for exotic corner use cases that people tried to come up with in the
> heat of the argument.
>

So, my issue is really with the proposition that we need a "good
argument" to support a toolkit version in the first place.

If the Firefox maintainers want to support two toolkit versions, more
power to them.

Gentoo is volunteer-based, and not a zero-sum game.  If you tell
somebody that they're not allowed to support A in the tree, that
doesn't mean that they'll have more time to support B instead.  It
probably just means that they'll spend less time contributing to
Gentoo.  In fact, if being prevented from supporting A makes Gentoo
less useful to them overall, they might just move to some other distro
and then not only do you lose A, but you lose C, D, and E.

That might be inefficient, but it is the result of depending on free
labor.  That's why we can have 400 unique window managers for X11 but
only one guy working in his spare time on openssl.  People work on the
stuff that interests them, not necessarily on what is most needed by
the general public.

The Firefox maintainers don't have to have a good reason to support
two versions of gtk.  As long as it generally builds/runs and complies
with security policy then they're allowed to do that, and our users
are better off for it.

You could look at any USE flag in the distro and make a case for how
we could probably get by without it.  After all, most distros don't
have USE flags at all and they seem to get by.

If somebody wants to go invent x32 in their spare time and maintain it
on Gentoo, more power to them, even if only 3 people use it.  I think
stuff like this is where Gentoo actually contributes the most to the
FOSS ecosystem.  We're a breeding ground for crazy but innovative
ideas and the best ones can get stolen by everybody else.  And just
like openssl nobody gives us much credit for it, but that's not why we
do it.

-- 
Rich

Re: [gentoo-dev] www-client/chromium gtk3 support

[Alec Ten Harmsel]

On Thu, Sep 10, 2015 at 03:07:16PM +0200, Michał Górny wrote:
> Dnia 2015-09-10, o godz. 08:46:41
> Alec Ten Harmsel  napisał(a):
> 
> > If upstream gives the option of gtk2 or gtk3, why shouldn't the ebuild?
> > From the "I want a usable system with as little code as possible" and "I
> > want a system tailored to my needs" standpoints, having only one version
> > of gtk makes quite a bit of sense.
> 
> This is the same case as with many other libraries which suffered major
> API changes -- SDL, for example. Just because upstream *thinks* they
> support two GTK+ versions, doesn't mean they do. Only one of the
> versions is well-tested, and the second one sometimes isn't tested at
> all, neither by upstream nor by the developer.

I'm sorry, I wrote too briefly. hasufell seems to be saying that gtk2
should be deprecated now. I'm just agreeing with Rich that if upstream
supports both *and* the maintainer wants to support both, there's no
reason to force them to only support one.

> The happy end result is, sometimes user has choice between 'working
> package' and 'package randomly segfaulting when you least expect it'.
> Of course, it's all hidden nicely under USE=gtk2 and USE=gtk3, so just
> *maybe* if you have the time to read local flag descriptions for every
> single package you may notice which of the flags should be enabled to
> get a working app.
> 
> But yes, wasting people's time and offering easy way to data loss is
> better than not supporting some imaginary corner case when you can
> actually use some fancy combination of applications that can actually
> run without that one library without losing stability and benefit you.
> 
> I hope you are ready to pay the developers who will waste their time
> figuring out what goes wrong when you report a bug, until they figure
> out it's because you have forced GTK+ version which upstream thought
> they're supporting but they do not. That's certainly a better
> alternative than paying for hardware that can handle loading two
> libraries.

As Rich has mentioned already, if upstream thinks they support gtk2 but
it crashes when using gtk2, I am perfectly fine with the maintainer
closing the bug as WONTFIX because upstream broke things.

Alec

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/10/2015 05:41 PM, Alec Warner wrote:
> 
> There are lots of topics where I concede that QA has a point and can
> utilize its influence; but 'consistency and usability' are not topics I
> would normally expect them to impose on developers.
> 

I am pretty sure tree consistency was the reason QA was founded.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Rich Freeman]

On Thu, Sep 10, 2015 at 11:41 AM, Alec Warner  wrote:
>
> On Thu, Sep 10, 2015 at 8:35 AM, hasufell  wrote:
>>
>>
>> If this affects tree consistency and usability, then it is not just up
>> to the maintainers.
>
> There are lots of topics where I concede that QA has a point and can utilize
> its influence; but 'consistency and usability' are not topics I would
> normally expect them to impose on developers.
>

Well, consistency as far as it involves compliance with standards
(PMS, tree policies, etc) certainly is fair game.  I don't think they
always need to be the ones creating the rules, though.

In any case, the whole versioned toolkit (gtk/qt/etc) flag issue is on
the council agenda.  I think this is an area that would benefit from a
policy, whether or not I end up agreeing with whatever the policy ends
up being.

Even if we end up deciding to push to not use versioned flags, we may
still end up having them for one-offs, and we'll still need policy on
how to properly control whether the gui gets built or not, and so on.
If we at least have a standard practice things will be easier on
everybody, and this is bigger than any one Gentoo team.  Of course
once a policy is established QA should by all means enforce it.

Also, I know that QA tends to get some knee-jerk reactions, but when
QA announces a policy it isn't like this is the end of the
conversation.  If you think they're making a mistake, you can always
talk to the QA lead, and appeal to the council.  For the most part I
think most of us try to be practical, even if we sometimes create a
mess before we realize what we're getting into.

-- 
Rich

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/10/2015 07:17 PM, Rich Freeman wrote:
>>
>> Given the fact that we are short on manpower and that most part of the
>> linux ecosystem is moving towards gtk3... there has been no good
>> argument to support a toolkit version - that is (about to be) deprecated
>> - for exotic corner use cases that people tried to come up with in the
>> heat of the argument.
>>
> 
> So, my issue is really with the proposition that we need a "good
> argument" to support a toolkit version in the first place.
> 

Because:
a) the gnome maintainers already said they are not interested in
supporting it indefinitely (they are the maintainers of gtk+ as well)
c) it introduces maintenance and configuration complexity where it is
absolutely unnecessary (because no one could come up with a real use
case) und breaks consistency

We _should_ need good arguments before we break consistency and
introduce another layer of configuration complexity, REQUIRED_USE flags
and other nastiness like package.stable.use.mask and whatnot (mgorny
already outlined a few other problems too).

Re: [gentoo-dev] www-client/chromium gtk3 support

[Rich Freeman]

On Thu, Sep 10, 2015 at 2:05 PM, hasufell  wrote:
> On 09/10/2015 07:17 PM, Rich Freeman wrote:
>>>
>>> Given the fact that we are short on manpower and that most part of the
>>> linux ecosystem is moving towards gtk3... there has been no good
>>> argument to support a toolkit version - that is (about to be) deprecated
>>> - for exotic corner use cases that people tried to come up with in the
>>> heat of the argument.
>>>
>>
>> So, my issue is really with the proposition that we need a "good
>> argument" to support a toolkit version in the first place.
>>
>
> Because:
> a) the gnome maintainers already said they are not interested in
> supporting it indefinitely (they are the maintainers of gtk+ as well)

I was not suggesting that anybody be forced to maintain gtk2 itself.
However, I don't see any efforts underway to remove it right now.
gtk2 isn't actually deprecated in Gentoo.  If it were then I'd look at
things differently.

If the day comes when nobody wants to maintain gtk2 in the tree, then
it will have to go.  If a single developer or proxy wants to maintain
it and does so, then it can stay.

And nothing in portage will be supported "indefinitely."

-- 
Rich

Re: [gentoo-dev] www-client/chromium gtk3 support

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/10/2015 01:47 AM, hasufell wrote:
> On 09/10/2015 08:21 AM, Daniel Campbell wrote:
>> 
>> For me to not support gtk2 in the spacefm ebuild would be
>> providing a package inferior to upstream.
> 
> That sounds like spacefm with gtk3 is lacking anything. It is not. 
> Providing choice for the sake of choice is not always a good idea.
> 

To my knowledge, the gtk3 version of spacefm *did* indeed have less
functionality, at first. I think they're mostly the same nowadays,
though. That said, I wasn't saying gtk3 support was lacking. But if
our package supports less things than upstreams, we're not shipping
/as complete/ a package.

For cases where either toolkit is unstable or doesn't work, I'm with
you: things that are unstable should either be clearly marked as such
or not added to the ebuild at all. But in spacefm's case, upstream
actively supports both toolkits and respects the user's choice.
Following suit here is the best idea, simply because we'd be providing
the same package and not forcing a choice on the user.

If there was something wrong with the gtk2 build -- let's say later on
gtk2 just goes unmaintained and starts breaking on Gentoo -- then
absolutely it should be removed. But for now, I think both should be
supported.

As for USE flag names, personally it doesn't really matter. I wouldn't
mind switching USE flag names, but as you said, we need consistency.
But as long as I'm maintainer of a package that gives users options
between toolkits, I will support them because as long as said toolkit
works, it's a sane choice that's *worth* supporting.

Of course, that's just my opinion and others are free to discard or
ridicule it as they see fit.

tldr: If the problem is USE flags, let's talk USE flags. If it's
supporting more than one toolkit in general, I see no reason not to
let maintainers use their discretion and not force their hand in
either direction.

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

iQIcBAEBCAAGBQJV8cimAAoJEAEkDpRQOeFw+jEQAIXcL7m+IEhDlt7pM8hQY3Bm
gTD0QzcDfXRV+wRkx35mhENXxPnT5hW/kxBYriUwfFFgKaG0BV8/Iv3P+J59J24l
R9QkgeZJ/DnWgTTYLfiY0tiRnua1g8CWTKG9mWRy1oaLKy0WOLnpcn90sBGVKk5O
qVWZditk16TiDPcbehPZQCUshnM1+INie3ANh2DeNrNJk6Lg2OmwPB5zeg8t70kn
cbnFEK1kansHVgglBoka/syY3oXrbEATL1xzLIkCCUp64V7+1yT+bwA1K79BJB9z
SVawPlI8CwaI3jGfT228gUCdyQzOdDa7ES9PHcMFuD5VettrVMdOpQ7Nm4RXIItt
LdsTGBjuZ2hu3sQRnsQcOLJQTFsWMUr7kMvBPkKwM8t/HDRJ6zfgP7ND8mi+CktE
rxa5KcbnOV3Kz13YtuS9SD7MdIjr4X/S4FTGhL23DXNGksltZ3+pRPMEHeV25a8l
opFYW55UK4Des1HK00glkLJTNsXx4Kv9/rSgh6hpATBKf66Ft9yZ7CtqJWx3EesU
QRfQ2T5PNDl2HNbybXvggQsg+oVnlPTpwRs2B5FlWHZfKxV+c5sWPtHPsxHpclw/
5W/YfUin5DnxBO8bCTk40rpeq3cTdUJkA2i2F63glCcOhXt2LGwq54uKg4GR6v38
nWi5NyH2vOwR5rhaqC5q
=oW5i
-END PGP SIGNATURE-

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/10/2015 08:15 PM, Daniel Campbell wrote:
> 
> To my knowledge, the gtk3 version of spacefm *did* indeed have less
> functionality, at first. I think they're mostly the same nowadays,
> though.

That's why spacefm ebuild did not switch to gtk3 when gtk3 support was
still experimental.

> That said, I wasn't saying gtk3 support was lacking. But if
> our package supports less things than upstreams, we're not shipping
> /as complete/ a package.
> 

This sentiment is very confusing. Not even spacefm provides all
available configure switches as USE flags and I am glad that it does not.

> 
> tldr: If the problem is USE flags, let's talk USE flags. If it's
> supporting more than one toolkit in general, I see no reason not to
> let maintainers use their discretion and not force their hand in
> either direction.
> 

We have provided several arguments here repeatedly.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Rich Freeman]

On Thu, Sep 10, 2015 at 2:21 PM, hasufell  wrote:
> On 09/10/2015 08:15 PM, Daniel Campbell wrote:
>>
>> tldr: If the problem is USE flags, let's talk USE flags. If it's
>> supporting more than one toolkit in general, I see no reason not to
>> let maintainers use their discretion and not force their hand in
>> either direction.
>>
>
> We have provided several arguments here repeatedly.
>

Well, right now the status quo is that this is up to maintainers.
There is no policy that states otherwise.

The USE flag issue is on the next council agenda, though I'm not
really confident that we'll resolve it in one go - there are only a
few days before the meeting.  If anybody has concerns about the
approach that we take I'd suggest posting them on the thread, but I
suspect that most likely the council will go around the circle and
assess where everybody generally stands, then propose something more
solid for a vote the following meeting (which gives everybody an
opportunity to shoot holes it in beforehand).

-- 
Rich

Re: [gentoo-dev] www-client/chromium gtk3 support

[Paweł Hajdan , Jr .]

On 9/10/15 8:05 PM, hasufell wrote:
> a) the gnome maintainers already said they are not interested in
> supporting it indefinitely (they are the maintainers of gtk+ as well)

Aren't there at least some gtk2-only apps? It seems to me we're not that
close to removal of gtk2 from the tree.

I'm also not aware of bugs being files about Gentoo gtk maintainers as a
result of gtk2/gtk3 USE flags on packages - please let me know if there
are in fact such bugs.

> c) it introduces maintenance and configuration complexity where it is
> absolutely unnecessary (because no one could come up with a real use
> case) und breaks consistency

Who decides whether a use case is valid? Clearly having discussions like
this for 10 years indicates people are interested in this.

I'm not saying a user is always right. I just wouldn't go out of my way
to block it if package maintainers are willing to support such requests.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] www-client/chromium gtk3 support

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/09/2015 03:37 AM, hasufell wrote:
> On 09/09/2015 09:24 AM, Daniel Campbell wrote:
>> 
>> x11-misc/spacefm supports multiple toolkits as well.
> 
> It shouldn't. Gtk3 is stable and gtk2 and gtk3 USE flags should be 
> removed to be consistent with the rest of the tree.
> 

Upstream deliberately supports GTK2 and GTK3 to provide users with
choice. The default choice in the ebuild is gtk3, falling in line with
gnome team's recommendations, but gtk2 is available for those who
prefer it that way.

For me to not support gtk2 in the spacefm ebuild would be providing a
package inferior to upstream. Given the divide among users over the
toolkit, I think it's fair to provide support for both where possible,
but lean in the direction of gtk3 for defaults so the Path of Least
Surprise is maintained.

If you have a better recommendation for allowing both toolkits being
supported, I'd be glad to read it.

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

iQIcBAEBCAAGBQJV8SFVAAoJEAEkDpRQOeFw7foP/iwWzIiae3m8N7isfviXsBFs
MQCH0SBlLjDVtTRucXBakTTxt9HUYUrQ3UnNe4ryalPHPZgS8bIC/s2r4S3Sds+o
3q9/jNCaMIKMq5TIu5HzGbIfThMIVslU6+DkDbIxTvN+QPIT+Jn+wmz7ca4K5HV1
LQxJ1+Rgb7Z3bj7yRrwLiGeGRNcbjz4skOJx077Hp0aXpK75706PEVYHftn9yLBM
r6UCY5tPhP7/oMC6tQyV2jvITrJtz4+RkBIJnrUvUA0aewlZskENMq0zSyGLZrCU
z+jf1H+wQQgs7COa+jvdBl4ItPiRJjA141SKjdkhOdRKNXhPNOqP2Ts7h6afpsil
TPZpB91DKE0RjhVxQQBAlnL9KZNF4z7RJ+F18W5mT8qdT/A8J2xeYXczGAKR+jO/
NFyD0IHu+4yvLHQxa8cPhxsxrlCKxrrLn+coKY+jXlouMaDyDaynYqJMZ0i6cXl2
QrGcYogeduLnZf1OvoM9RWk9GbGnKNXR5F0xDCR+BOas6BOGilu44z0QhhPhm0cW
ehXJnKhU76bVLXRDNP71iMir8SoC1E/mD2HTyeRds3nUD7YuflZ6CrBvdmT+P9IG
8LDqW91/uWavgyMGOuXWN5w8rMUR6o1k1ID9/tNbH+JkQepKcs9PGs2tXuPRfOJ8
DnO93xAVLVPXcLu0U251
=ZLIv
-END PGP SIGNATURE-

Re: [gentoo-dev] www-client/chromium gtk3 support

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/09/2015 06:47 AM, Alexandre Rostovtsev wrote:
> On Wed, 2015-09-09 at 09:20 +0200, Paweł Hajdan, Jr. wrote:
> 
> In chromium's case (a new gtk3-based ui that needs wider testing),
> a local gtk3 USE flag does make sense.
> 
> But in general, the gnome team recommends avoiding the gtk3 flag 
> whenever possible. We definitely don't want it to become a global
> flag. We are trying to avoid the following scenario:
> 
> (1) Dozens of ebuilds add gtk3 USE flag, and the semantics of the
> gtk3 flag differ wildly in those ebuilds: (a) build an optional gui
> that happens to be based on gtk3 (instead of no gui at all); (b)
> build experimental gtk3-based gui (instead of stable gtk2 gui as 
> recommended by upstream); (c) build recommended gtk3-based gui
> (instead of legacy gtk2-based gui which is not supported by
> upstream any more); (d) build widget library and utilities for gtk3
> (possibly in parallel with gtk2 widgets and utilities); (e) build
> widget library and utilities for gtk3 (and disable gtk2 widgets and
> utilities - without making any effort to allow both gtk2 and gtk3
> support in parallel by splitting the package or renaming a few
> files). (3) Since the flag is used all over the place, some users
> try to globally enable or disable it, depending on their personal
> feelings about Adwaita's tab shapes. (4) Since the flag sometimes
> means "build a gui (instead of no gui at all)" at some point it
> gets globally enabled in some profile. (5) Users are forced to
> maintain giant lists of package.use entries to get a usable desktop
> environment. Unhappiness reigns.
> 
> In other words, to avoid the scenario that happened during
> gtk1/gtk2 transition, and which is now starting with qt4/qt5 [1].
> 
> [1]
> https://archives.gentoo.org/gentoo-dev/message/11e3d077e0d9c953597c3d1
7f327c6b3
>
> 
How do you propose packages whose upstreams maintain both gtk2 and
gtk3 builds but don't actively push one over the other be packaged? I
currently have gtk3 and gtk2 flags, but it defaults to gtk3. Should
the gtk3 flag actually be just `gtk` to fall in line with the latest
version, and `gtk2` provide the expected versioned toolkit?

The package in question is a GUI package, so *some* toolkit version
needs to be chosen. Defaulting to gtk3 falls in line with gnome-team's
opinions while still offering gtk2 support. I think limiting it to
*only* gtk3 would be doing our users a disservice.

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

iQIcBAEBCAAGBQJV8SMpAAoJEAEkDpRQOeFwzUIQAIMq1BjmnMpevMquOQsoQG4p
uOev7ndC/lyIyV+S0IRyu8QdlVU3iEuMZHDlu6dtz/jJTDTZ6OjC6yQ4NifYd5nE
O16D5u2+diYqpBkCjXo2evLRSvHhMrLt6lmzXkHjJkE4zC1jH3faI6x0keZIro2N
QSaY9pMqfnSET45VuQ632NxgbdZPXc4YpvIty0/AHk86uDuU9aZMyRH6ZpiMp7iu
aGaNyiRXpL1rlRxXD0ppOM6h7gU0MFIAdA1UQqlgbowchX7/T93dBehOXAO3Z38C
ANLEuqPVOqYLaR0P8VLXYUIlusx1tbAUIBSy7ZIyr1s7gUsgi9IkwAAIObsrhf66
oy0MNFS0oiEVrnUYxLyd3XnAKo8XKUFq3ZTn8m41IZKP21fSGyVhmccrhnmXjYv9
k1DC0kMjWPOhtO/8/rdZekoJZYOmXE76HMh74YdMca7DP9E2/WEpuu4P9qUs5EVl
8mjCLZEwTOex96sRt+OiXDxNP0iMA/hllHbdmJsw1BIZhz3wqMi0msUQhmOi2sSt
SZQD+KwonbTYZmEAq2GV0pyEaLO8nC6jCj+vqfAZlrM/IUPKeKFnElNrbORfVqSp
ye/cT4ScmPVpmsEZqB+GizNfX4sue21FHnm7RZpJdIZig2dd9Qjn9LSF0gSwKymK
Zncie7DhlImRSULbsBr4
=13Ur
-END PGP SIGNATURE-

[gentoo-dev] www-client/chromium gtk3 support

[Paweł Hajdan , Jr .]

A user asked for optional gtk3 support in www-client/chromium:


However, reading e.g.

says this:

> having USE=gtk3 to enable gtk+-3 instead of gtk+-2 support is
> forbidden

> package is an application with support for multiple gtk+, maintainer
> is free to select whatever slot he desires to support. It is strongly
> advised to use gtk+-3 if functionality is equivalent. This is to
> reduce workload of bugs being triggered with one slot but not the
> other.

What are your recommendations for the best course of action?

For stability and maintainability, I'd prefer www-client/chromium to use
the upstream defaults (gtk+-2 AFAIK) since it's most common, tested, and
supported configuration. If/when upstream moves to gtk+-3, we'd just follow.

I also understand we have users who are eager to run various
configurations, and expect Gentoo to be flexible and allow that. Would
masking a gtk3 USE flag for www-client/chromium be acceptable? Are there
any other solutions that might work?

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] www-client/chromium gtk3 support

[Andrew Savchenko]

On Wed, 9 Sep 2015 00:24:55 -0700 Daniel Campbell wrote:
> > For stability and maintainability, I'd prefer www-client/chromium
> > to use the upstream defaults (gtk+-2 AFAIK) since it's most common,
> > tested, and supported configuration. If/when upstream moves to
> > gtk+-3, we'd just follow.
> > 
> > I also understand we have users who are eager to run various 
> > configurations, and expect Gentoo to be flexible and allow that.
> > Would masking a gtk3 USE flag for www-client/chromium be
> > acceptable? Are there any other solutions that might work?
> > 
> > Paweł
> > 
> x11-misc/spacefm supports multiple toolkits as well. I stay in line
> with GNOME suggestions by making gtk3 the default, but gtk2
> configurable via USE. Versioned USE flags are generally frowned upon,
> but I see no better way to support both a GTK3 default *and* allow for
> the GTK2 support. Part of the reason I came to Gentoo (and became a
> dev) is to support user choice, and personally as a maintainer that
> matters more than suggestions.
> 
> If the GNOME team has a solid recommendation for supporting both GTK2
> and 3, I'll read it. But for now, defaulting IUSE to gtk3 and allowing
> the user to set gtk2 is the best of both worlds imo.

The chromium upstream recommends gtk2, so it should be the default,
even if the GNOME team recommends gtk3.

Best regards,
Andrew Savchenko


pgpQkR30y3SMr.pgp
Description: PGP signature

Re: [gentoo-dev] www-client/chromium gtk3 support

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/09/2015 12:20 AM, Paweł Hajdan, Jr. wrote:
> A user asked for optional gtk3 support in www-client/chromium: 
> 
> 
> However, reading e.g. 
> 
>
> 
says this:
> 
>> having USE=gtk3 to enable gtk+-3 instead of gtk+-2 support is 
>> forbidden
> 
>> package is an application with support for multiple gtk+,
>> maintainer is free to select whatever slot he desires to support.
>> It is strongly advised to use gtk+-3 if functionality is
>> equivalent. This is to reduce workload of bugs being triggered
>> with one slot but not the other.
> 
> What are your recommendations for the best course of action?
> 
> For stability and maintainability, I'd prefer www-client/chromium
> to use the upstream defaults (gtk+-2 AFAIK) since it's most common,
> tested, and supported configuration. If/when upstream moves to
> gtk+-3, we'd just follow.
> 
> I also understand we have users who are eager to run various 
> configurations, and expect Gentoo to be flexible and allow that.
> Would masking a gtk3 USE flag for www-client/chromium be
> acceptable? Are there any other solutions that might work?
> 
> Paweł
> 
x11-misc/spacefm supports multiple toolkits as well. I stay in line
with GNOME suggestions by making gtk3 the default, but gtk2
configurable via USE. Versioned USE flags are generally frowned upon,
but I see no better way to support both a GTK3 default *and* allow for
the GTK2 support. Part of the reason I came to Gentoo (and became a
dev) is to support user choice, and personally as a maintainer that
matters more than suggestions.

If the GNOME team has a solid recommendation for supporting both GTK2
and 3, I'll read it. But for now, defaulting IUSE to gtk3 and allowing
the user to set gtk2 is the best of both worlds imo.

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

iQIcBAEBCAAGBQJV797CAAoJEAEkDpRQOeFwcl4P+wUAQwjoVCdvEjELYxSpgHZS
I6xd+YOikyRuio68+UB1pBeJpFkZkblQ7DS6loK8eIQFSM+C3RQ1bM2Qa/iQ7he4
4X5NNDVMI8UgT568TsH0d6k/AuUxGuRlH6lrMKOdXZfrCen/pl0QLTtWkI+sOzh4
hAxDKoXf3CntmIrwCp2bsTDyU79uX+X2mQHnjz49U7FXYWc+WDPMaFK1dQzp59wD
vLnMFNoh27gVSWNwsYiy6yo7hL73vIF2ZQaiYnQDKR3nxOLvWLTsCY6JSfebSJiX
bv/dyUldcjK4vaEaES0+PYHVww7A3f13QbC3b3/8oTxAHfMZpYCWnskUN1hCx337
I+/LBR2KrSsoyLPNNfMuVk0t4h2TEQw2SHED4+ObQ2qQ4tc1SmdWPn3g//2e8cFU
Zl2fLxfrXiQxCUB5dByUXSzD1lPCo7BvespewoJ3g+YkeZpxfQ4iyt91otG8sooW
VNJF/+gqgBSGnJPZQBjx1n6bjx08B++pCoybvZGn2NUHvLpYe/rgA3oZyg0clZND
dEbkgXbbn3dJMbiaTzT7ou2Icv0T0F7+xHxq4IFvZ7NgthrNhmTFllWsgC0rpM3/
RLwjFfaekap1utGew5W3+77xyKIxDIeBFGQm0pP7KgQDHn+M6Cs5+r64vljDXsWp
0MYg19z2jBdxbCpaMxET
=Q16B
-END PGP SIGNATURE-

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/09/2015 09:24 AM, Daniel Campbell wrote:
> 
> x11-misc/spacefm supports multiple toolkits as well. 

It shouldn't. Gtk3 is stable and gtk2 and gtk3 USE flags should be
removed to be consistent with the rest of the tree.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Brian Dolbec]

On Wed, 9 Sep 2015 12:37:49 +0200
hasufell  wrote:

> On 09/09/2015 09:24 AM, Daniel Campbell wrote:
> > 
> > x11-misc/spacefm supports multiple toolkits as well. 
> 
> It shouldn't. Gtk3 is stable and gtk2 and gtk3 USE flags should be
> removed to be consistent with the rest of the tree.
> 

to hell with stable, IMHO gtk3 is just crap and nearly destroys all
usability,  I have mostly gtk2, with some gtk3, and I'd love to nuke
the rest of the gtk3 ones...  So, if chromium goes gtk3, I'll be
looking for a new browser.  and if gentoo drops gtk2, I'll be looking
for a new DE...

-- 
Brian Dolbec 

Re: [gentoo-dev] www-client/chromium gtk3 support

[Alexandre Rostovtsev]

On Wed, 2015-09-09 at 09:20 +0200, Paweł Hajdan, Jr. wrote:

In chromium's case (a new gtk3-based ui that needs wider testing), a
local gtk3 USE flag does make sense.

But in general, the gnome team recommends avoiding the gtk3 flag
whenever possible. We definitely don't want it to become a global flag.
We are trying to avoid the following scenario:

(1) Dozens of ebuilds add gtk3 USE flag, and the semantics of the gtk3
flag differ wildly in those ebuilds:
  (a) build an optional gui that happens to be based on gtk3 (instead
  of no gui at all);
  (b) build experimental gtk3-based gui (instead of stable gtk2 gui as
  recommended by upstream);
  (c) build recommended gtk3-based gui (instead of legacy gtk2-based
  gui which is not supported by upstream any more);
  (d) build widget library and utilities for gtk3 (possibly in parallel
  with gtk2 widgets and utilities);
  (e) build widget library and utilities for gtk3 (and disable gtk2
  widgets and utilities - without making any effort to allow both
  gtk2 and gtk3 support in parallel by splitting the package or
  renaming a few files).
(3) Since the flag is used all over the place, some users try to
globally enable or disable it, depending on their personal feelings
about Adwaita's tab shapes.
(4) Since the flag sometimes means "build a gui (instead of no gui at
all)" at some point it gets globally enabled in some profile.
(5) Users are forced to maintain giant lists of package.use entries to
get a usable desktop environment. Unhappiness reigns.

In other words, to avoid the scenario that happened during gtk1/gtk2
transition, and which is now starting with qt4/qt5 [1].

[1] 
https://archives.gentoo.org/gentoo-dev/message/11e3d077e0d9c953597c3d17f327c6b3



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/09/2015 03:17 PM, Brian Dolbec wrote:
> On Wed, 9 Sep 2015 12:37:49 +0200
> hasufell  wrote:
> 
>> On 09/09/2015 09:24 AM, Daniel Campbell wrote:
>>>
>>> x11-misc/spacefm supports multiple toolkits as well. 
>>
>> It shouldn't. Gtk3 is stable and gtk2 and gtk3 USE flags should be
>> removed to be consistent with the rest of the tree.
>>
> 
> to hell with stable, IMHO gtk3 is just crap and nearly destroys all
> usability,  I have mostly gtk2, with some gtk3, and I'd love to nuke
> the rest of the gtk3 ones...  So, if chromium goes gtk3, I'll be
> looking for a new browser.  and if gentoo drops gtk2, I'll be looking
> for a new DE...
> 


I haven't encountered a gtk app (I develop some myself) that has dropped
significant features in the process of migration to gtk3, but I
obviously don't use all of them.

IMO, there's pretty much no difference for the user, except that the
codepaths are better maintained.

You can have the exact same usability with gtk3 as with gtk2. That's
developer choice, not toolkit related. When upstream developers drop
features or even toolkit support, you don't want to ship legacy code to
the user.

So this is just a transition period anyway and we shouldn't confuse our
users with temporary USE flags that break consistency, unless that's
absolutely necessary.

Again: usability is not predefined in the toolkit. This is not about gnome3.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Mike Gilbert]

On Wed, Sep 9, 2015 at 3:20 AM, Paweł Hajdan, Jr.  wrote:
> A user asked for optional gtk3 support in www-client/chromium:
> 
>
> However, reading e.g.
> 
> says this:
>
>> having USE=gtk3 to enable gtk+-3 instead of gtk+-2 support is
>> forbidden
>
>> package is an application with support for multiple gtk+, maintainer
>> is free to select whatever slot he desires to support. It is strongly
>> advised to use gtk+-3 if functionality is equivalent. This is to
>> reduce workload of bugs being triggered with one slot but not the
>> other.
>
> What are your recommendations for the best course of action?
>
> For stability and maintainability, I'd prefer www-client/chromium to use
> the upstream defaults (gtk+-2 AFAIK) since it's most common, tested, and
> supported configuration. If/when upstream moves to gtk+-3, we'd just follow.
>
> I also understand we have users who are eager to run various
> configurations, and expect Gentoo to be flexible and allow that. Would
> masking a gtk3 USE flag for www-client/chromium be acceptable? Are there
> any other solutions that might work?

I would really like a way to toggle gtk3 for testing. If you don't
want to expose it as a 'supported' option for users, then masking it
sounds fine to me.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Alexandre Rostovtsev]

On Wed, 2015-09-09 at 11:00 -0400, Mike Gilbert wrote:
> I would really like a way to toggle gtk3 for testing. If you don't
> want to expose it as a 'supported' option for users, then masking it
> sounds fine to me.

Then add the flag, document it in metadata.xml.

But in general, try to avoid using this flag in your ebuilds if
possible, the gnome team *really* doesn't want to turn gtk3 into a
global USE flag with uncertain semantics.

signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] www-client/chromium gtk3 support

[Alec Warner]

On Wed, Sep 9, 2015 at 8:10 AM, Alexandre Rostovtsev 
wrote:

> On Wed, 2015-09-09 at 11:00 -0400, Mike Gilbert wrote:
> > I would really like a way to toggle gtk3 for testing. If you don't
> > want to expose it as a 'supported' option for users, then masking it
> > sounds fine to me.
>
> Then add the flag, document it in metadata.xml.
>
> But in general, try to avoid using this flag in your ebuilds if
> possible, the gnome team *really* doesn't want to turn gtk3 into a
> global USE flag with uncertain semantics.


The best way to avoid this IMHO is to not name the flag the same thing.

if you named the chromium flag "experimental-gtk3-ui' or similar, then
users would be unable to turn it on by just setting 'gtk3'

-A

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/09/2015 05:40 PM, Ian Stakenvicius wrote:
> 
> app-editors/emacs
> app-editors/emacs-vcs
> app-editors/mousepad
> app-i18n/fcitx
> app-i18n/fcitx-configtool
> app-i18n/ibus
> app-i18n/ibus-unikey
> app-i18n/imsettings
> app-i18n/scim
> app-i18n/scim-anthy
> app-i18n/uim
> app-misc/emelfm2
> dev-libs/libdbusmenu
> dev-python/matplotlib
> dev-util/geany
> kde-plasma/plasma-desktop
> lxde-base/lxdm
> mail-client/claws-mail
> media-gfx/geeqie
> media-libs/libcanberra
> media-plugins/audacious-plugins
> media-sound/audacious
> media-sound/easytag
> media-sound/mp3splt-gtk
> net-analyzer/pinger
> net-dns/avahi
> net-libs/gtk-vnc
> net-misc/dhcpcd-ui
> net-misc/electrum
> net-misc/spice-gtk
> www-client/dwb
> www-client/uget
> www-client/uzbl
> www-client/vimb
> www-plugins/freshplayerplugin
> x11-drivers/nvidia-drivers
> x11-misc/light-locker
> x11-misc/spacefm
> x11-themes/light-themes
> xfce-base/libxfce4ui
> xfce-extra/xfce4-taskmanager
> 
> 

There was a tracker on bugzilla about it at some point, but people
didn't care enough, so I stopped filing bugs. Neither the gnome team nor
QA had a strong enough opinion to enforce consistency here over the
whole tree.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/09/15 11:48 AM, hasufell wrote:
> On 09/09/2015 05:40 PM, Ian Stakenvicius wrote:
>> 
>> [ Snip list ]
>> 
> 
> There was a tracker on bugzilla about it at some point, but
> people didn't care enough, so I stopped filing bugs. Neither the
> gnome team nor QA had a strong enough opinion to enforce
> consistency here over the whole tree.
> 


Right... So, back to the issue at hand.  If a package -always-
depends on a gtk (usually gtk2), but can optionally be configured to
depend on gtk3 instead (and it should be optional because support
isn't clearly stable yet), what's the solution here?

IUSE="gtk" isn't appropriate because that's meant for enabling
optional gtk support, not choosing -which- gtk to support when there
always needs to be one.  IUSE="gtk3" to me fits well in this case
but it's also reportedly forbidden...
IUSE="experimental-gtk3-support" seems less than optimal but if we
(chromium, mozilla teams) have to go that route I guess we will..

The wiki seems to say that we as rdep maintainers should choose one
and stick with it, but as a mozilla package maintainer, I don't want
to force the entire user base to using one or the other (at least
not yet), given firefox -just- got (that is, will get in two version
bumps) gtk3 support that's considered stable enough for use outside
of development.

I don't suppose we as a community can revisit the decision to ban
IUSE="gtk3" as a flag to toggle between gtk2 and gtk3 support, when
one or the other is -required- by a package?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXwWuYACgkQAJxUfCtlWe25WwD/b8ozgV4zHLyNrIzYI+Cu79+l
gBORP+1q6EMUWyuyVewBAIE3nNFow+XeN67pH4pT6gqQqBJ27VH+bAt9nTprs0pi
=HWeR
-END PGP SIGNATURE-

Re: [gentoo-dev] www-client/chromium gtk3 support

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/09/15 11:16 AM, Alec Warner wrote:
> 
> 
> On Wed, Sep 9, 2015 at 8:10 AM, Alexandre Rostovtsev 
> > wrote:
> 
> On Wed, 2015-09-09 at 11:00 -0400, Mike Gilbert wrote:
>> I would really like a way to toggle gtk3 for testing. If you
>> don't want to expose it as a 'supported' option for users, then
>> masking it sounds fine to me.
> 
> Then add the flag, document it in metadata.xml.
> 
> But in general, try to avoid using this flag in your ebuilds if 
> possible, the gnome team *really* doesn't want to turn gtk3 into
> a global USE flag with uncertain semantics.
> 
> 
> The best way to avoid this IMHO is to not name the flag the same
> thing.
> 
> if you named the chromium flag "experimental-gtk3-ui' or similar,
> then users would be unable to turn it on by just setting 'gtk3'
> 

Is it worth noting that there are dozens of packages in the tree
right now that have a gtk3 flag in IUSE?  Many have 'gtk gtk3'
combinations, and many others have 'gtk3' entirely on their own:

app-editors/emacs
app-editors/emacs-vcs
app-editors/mousepad
app-i18n/fcitx
app-i18n/fcitx-configtool
app-i18n/ibus
app-i18n/ibus-unikey
app-i18n/imsettings
app-i18n/scim
app-i18n/scim-anthy
app-i18n/uim
app-misc/emelfm2
dev-libs/libdbusmenu
dev-python/matplotlib
dev-util/geany
kde-plasma/plasma-desktop
lxde-base/lxdm
mail-client/claws-mail
media-gfx/geeqie
media-libs/libcanberra
media-plugins/audacious-plugins
media-sound/audacious
media-sound/easytag
media-sound/mp3splt-gtk
net-analyzer/pinger
net-dns/avahi
net-libs/gtk-vnc
net-misc/dhcpcd-ui
net-misc/electrum
net-misc/spice-gtk
www-client/dwb
www-client/uget
www-client/uzbl
www-client/vimb
www-plugins/freshplayerplugin
x11-drivers/nvidia-drivers
x11-misc/light-locker
x11-misc/spacefm
x11-themes/light-themes
xfce-base/libxfce4ui
xfce-extra/xfce4-taskmanager

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXwUvcACgkQAJxUfCtlWe3oBgEAvr7nBfDygUPG4MGiK23ya3Xn
RRWLOkprA6SuFjbef84BAJehMtEtt+ZqC3HzGJ5yroM+yCqQE855uQz7+2mpGeyC
=LOpM
-END PGP SIGNATURE-

Re: [gentoo-dev] www-client/chromium gtk3 support

[hasufell]

On 09/09/2015 06:14 PM, Ian Stakenvicius wrote:
> 
> 
> Right... So, back to the issue at hand.  If a package -always-
> depends on a gtk (usually gtk2), but can optionally be configured to
> depend on gtk3 instead (and it should be optional because support
> isn't clearly stable yet), what's the solution here?
> 

Provide the gtk3 version in an overlay (without gtk3 USE flag), because
that's where experimental stuff belongs. If people want to test it, they
can do it an we don't have to use ugly stuff like package.use.stable.mask.

Re: [gentoo-dev] www-client/chromium gtk3 support

[Paweł Hajdan , Jr .]

On 9/9/15 5:48 PM, hasufell wrote:
> There was a tracker on bugzilla about it at some point, but people 
> didn't care enough, so I stopped filing bugs. Neither the gnome team
> nor QA had a strong enough opinion to enforce consistency here over
> the whole tree.

Looks like that was  .

I'm not sure whether the underlying issue was enforcement, or just
handling various use cases.

Similar situation with qt/qt4/qt5 seems to confirm to me that it's not
whims that make people not follow the policy, but real needs and use cases.

Quotes from above bug:

> You really have not addressed all the situations here.

> Yes I know there may be situations where the proposed solutions are
> not sufficient.

Also, most blocking bugs seem to be resolved as WONTFIX/WORKSFORME/INVALID.

FWIW I do care. For now responses on this thread seem to recommend (or
be at least OK with) adding gtk3 USE flag to www-client/chromium . If
there's an alternative solution endorsed by GNOME or QA team that would
make progress on 
possible, I'd just switch to that solution.

Paweł



signature.asc
Description: OpenPGP digital signature