On Thu, Sep 10, 2015 at 9:07 AM, Michał Górny <[email protected]> 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
