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 09E20138454 for ; Thu, 10 Sep 2015 18:15:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 61220E08F4; Thu, 10 Sep 2015 18:15:03 +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 63031E08C2 for ; Thu, 10 Sep 2015 18:15:02 +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 4087333BF0B for ; Thu, 10 Sep 2015 18:15:00 +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> From: Daniel Campbell X-Enigmail-Draft-Status: N1110 Message-ID: <55F1C8AB.40005@gentoo.org> Date: Thu, 10 Sep 2015 11:15:07 -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: <55F1439E.1070002@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: f180eb1c-e7ff-4959-9e1f-2866129a2acb X-Archives-Hash: 8955c50e30b8d8e5206267613b18069a -----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-----