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 1A9BD138454 for ; Fri, 11 Sep 2015 09:03:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B750021C015; Fri, 11 Sep 2015 09:03:08 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C2655E0806 for ; Fri, 11 Sep 2015 09:03:07 +0000 (UTC) Received: from [192.168.1.2] (c-73-53-75-119.hsd1.wa.comcast.net [73.53.75.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zlg) by smtp.gentoo.org (Postfix) with ESMTPSA id A58CF340A59 for ; Fri, 11 Sep 2015 09:03:05 +0000 (UTC) Subject: Re: [gentoo-dev] www-client/chromium gtk3 support To: gentoo-dev@lists.gentoo.org References: <55EFDDAD.9030502@gentoo.org> <55EFDEC7.1070403@gentoo.org> <55F00BFD.7050804@gentoo.org> <55F12159.3020506@gentoo.org> <55F1439E.1070002@gentoo.org> <55F1C8AB.40005@gentoo.org> <55F1CA38.3050302@gentoo.org> From: Daniel Campbell X-Enigmail-Draft-Status: N1110 Message-ID: <55F298D0.7020702@gentoo.org> Date: Fri, 11 Sep 2015 02:03:12 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: b9243a5c-4eb7-4591-8c07-cca685659fcf X-Archives-Hash: 5becf3ed30ecf2e1d4b700ce7c2498bd -----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-----