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

[Rich Freeman]

On Thu, Sep 10, 2015 at 9:07 AM, Michał Górny <mgorny@g.o> 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