From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 47539138454 for ; Thu, 10 Sep 2015 13:20:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B62F821C067; Thu, 10 Sep 2015 13:20:03 +0000 (UTC) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E1B9E21C004 for ; Thu, 10 Sep 2015 13:20:02 +0000 (UTC) Received: by iofb144 with SMTP id b144so60257163iof.1 for ; Thu, 10 Sep 2015 06:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=KlwUwGpy8ewYCGaSOqk+FFc47h0GME6SgCrftvGeZus=; b=Y3iuBTKVwgkQnnGcHh+ryyXH9PYrLQu2GuQCfGutVAzwummC4DD1YlPfCkkOproGs4 PEe2U4Q573Uu+Rslfs+pj/6KKaOtWgb22qN2W38Y8koFFE5h7aWtrIBQGPWvRIMxqFJ5 5NXu9drbZK0b2+xoh6Ey7YY2v3HhhjoJox299eRtLIHS9UGORiCxb9VsUNoc+wpJEugi mC819wzOBP9Ls2QnXK9/FWYvXXTpyVwjV+ONrCHCWnNcDuv8LibfI0/Eq82EbxcCPFbt XGOwr7bh3KMjBEh7cYde0345knu0mgdfIxL3hdIUsQJcHHuc7hgTlWMzEx2RWxxDt4XV WDgg== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.107.46.12 with SMTP id i12mr62305333ioo.17.1441891202199; Thu, 10 Sep 2015 06:20:02 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.79.103.70 with HTTP; Thu, 10 Sep 2015 06:20:02 -0700 (PDT) In-Reply-To: <20150910150716.5a843cc7.mgorny@gentoo.org> References: <55EFDEC7.1070403@gentoo.org> <55F00BFD.7050804@gentoo.org> <55F12159.3020506@gentoo.org> <55F1439E.1070002@gentoo.org> <55F16059.9090502@gentoo.org> <55F173F3.7040806@gentoo.org> <55F17885.2050103@gentoo.org> <20150910124641.GB6567@greenbeast> <20150910150716.5a843cc7.mgorny@gentoo.org> Date: Thu, 10 Sep 2015 09:20:02 -0400 X-Google-Sender-Auth: WRKEJl_oJHMDn0-vMjSH5wIwFHk Message-ID: Subject: Re: [gentoo-dev] www-client/chromium gtk3 support From: Rich Freeman To: gentoo-dev Cc: Alec Ten Harmsel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 0f269651-25ad-46df-9c71-054065321fbe X-Archives-Hash: c3ed3155dbb7708218a9942c18175a55 On Thu, Sep 10, 2015 at 9:07 AM, Micha=C5=82 G=C3=B3rny = 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=3Dgtk2 and USE=3Dgtk3, so jus= t > *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=3Dgtk2 or USE=3Dgtk3 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. --=20 Rich