From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-71951-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 30243138454 for <garchives@archives.gentoo.org>; Thu, 10 Sep 2015 16:24:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8CFC4E08F9; Thu, 10 Sep 2015 16:24:22 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7A6EDE08F3 for <gentoo-dev@lists.gentoo.org>; Thu, 10 Sep 2015 16:24:21 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2E8A3205A5 for <gentoo-dev@lists.gentoo.org>; Thu, 10 Sep 2015 12:24:21 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 10 Sep 2015 12:24:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=nonyY0BVeRQT+Xk QLSpuedtR99M=; b=rxk3v/f9Tbed9nRxowbZ6a0uSpg/1Ngf7uBNXn62uRbBviN WCuIxWk/palyCsrbutJUMuwBcxA0Kf67xOUHTvsik81+OsHYucKCsm9kYnjJPsZ2 Mzb9Dhapy8OUXdGP/WXcgFZb1mSn46AO/LoxwEFA1vWqZrbt1TIcs/5/Zaw8= X-Sasl-enc: F9tqGCRdCurQ0wsAW5RD6HgJ18UDjrsid3/jhbT/EOwX 1441902260 Received: from apio.adsroot.itcs.umich.edu (0587357915.wireless.umich.net [35.2.94.219]) by mail.messagingengine.com (Postfix) with ESMTPA id D273AC00020; Thu, 10 Sep 2015 12:24:20 -0400 (EDT) Date: Thu, 10 Sep 2015 12:24:14 -0400 From: Alec Ten Harmsel <alec@alectenharmsel.com> To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] www-client/chromium gtk3 support Message-ID: <20150910162414.GA669@apio.adsroot.itcs.umich.edu> References: <55F12159.3020506@gentoo.org> <55F1439E.1070002@gentoo.org> <CAGfcS_kMxJ4mKE88-R9BwAG0PMrrB6j_HR87f9uWFvNH-hCWvw@mail.gmail.com> <55F16059.9090502@gentoo.org> <CAGfcS_nE8E_qKcB3va=iefaMKWTT1HjCgvppOH7C69tw5YS5vw@mail.gmail.com> <55F173F3.7040806@gentoo.org> <CAGfcS_=_d89aMDDBvR9mBqmFe528DtHhbCq8C11cQyWS3i2+PQ@mail.gmail.com> <55F17885.2050103@gentoo.org> <20150910124641.GB6567@greenbeast> <20150910150716.5a843cc7.mgorny@gentoo.org> Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150910150716.5a843cc7.mgorny@gentoo.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Archives-Salt: cfd48c4f-2be1-4667-9ca9-88d22e31edcd X-Archives-Hash: ed03a6a6ce8d2092fcee232feb665f76 On Thu, Sep 10, 2015 at 03:07:16PM +0200, Michał Górny wrote: > Dnia 2015-09-10, o godz. 08:46:41 > Alec Ten Harmsel <alec@alectenharmsel.com> napisał(a): > > > If upstream gives the option of gtk2 or gtk3, why shouldn't the ebuild? > > From the "I want a usable system with as little code as possible" and "I > > want a system tailored to my needs" standpoints, having only one version > > of gtk makes quite a bit of sense. > > This is the same case as with many other libraries which suffered major > API changes -- SDL, for example. Just because upstream *thinks* they > support two GTK+ versions, doesn't mean they do. Only one of the > versions is well-tested, and the second one sometimes isn't tested at > all, neither by upstream nor by the developer. I'm sorry, I wrote too briefly. hasufell seems to be saying that gtk2 should be deprecated now. I'm just agreeing with Rich that if upstream supports both *and* the maintainer wants to support both, there's no reason to force them to only support one. > 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. > > But yes, wasting people's time and offering easy way to data loss is > better than not supporting some imaginary corner case when you can > actually use some fancy combination of applications that can actually > run without that one library without losing stability and benefit you. > > 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. As Rich has mentioned already, if upstream thinks they support gtk2 but it crashes when using gtk2, I am perfectly fine with the maintainer closing the bug as WONTFIX because upstream broke things. Alec