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 5309A138D07 for ; Thu, 13 Feb 2014 00:23:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B1C65E0B47; Thu, 13 Feb 2014 00:23:00 +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 BA39CE0B40 for ; Thu, 13 Feb 2014 00:22:59 +0000 (UTC) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mattst88) by smtp.gentoo.org (Postfix) with ESMTPSA id DF1B333F91A for ; Thu, 13 Feb 2014 00:22:58 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id w7so16804747qcr.28 for ; Wed, 12 Feb 2014 16:22:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=cGxUTFoAlZHZSogDTYkhOPdo6theQiHkbc9ZHPohhiI=; b=eOoPGZnJH3eEJIlmVresu4B6J68lsNHWvXuCyJIN9M4R/BflZQpLzwGWLlQ5wjLktJ q9LPmOOQjtaZ3ZyKvELgDYEEpCe8+sSgGXt2ePWrViqOmlW8eCK+iQpY+AuPgsKYF3NQ czAmcxv47ZOeyr6NxDsjX8SI7eIYQJSonePGCzXALoCqgeSxZMYblmy7sEOV8FXnnV+K pcLedDZARHDfTykNlzMo1UF9h3OCujdg/8ZaDrb1QIe8NN752DZ8DTUkr9nEccd7WD0S fKjcikxxYDmnw35t91RgX8gk2++CArt1icWTEnmVYdEbM6557WGgqh97FrIqKGWggRWq wozg== X-Received: by 10.140.29.38 with SMTP id a35mr69600687qga.55.1392250976838; Wed, 12 Feb 2014 16:22:56 -0800 (PST) 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 Received: by 10.229.8.198 with HTTP; Wed, 12 Feb 2014 16:22:36 -0800 (PST) In-Reply-To: <52FBF9D6.7010104@gentoo.org> References: <20140211223913.GB26141@fury> <1392160421.31609.2.camel@kanae> <52FAC142.3000602@gentoo.org> <20140212090954.7c4825ba@pomiot.lan> <52FBF9D6.7010104@gentoo.org> From: Matt Turner Date: Wed, 12 Feb 2014 16:22:36 -0800 Message-ID: Subject: Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493) To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 5e0c80a4-787d-4a61-859a-7eaba004f124 X-Archives-Hash: 275a4e1e6fe555c24066b451ddde564c On Wed, Feb 12, 2014 at 2:46 PM, Chris Reffett wrote: > On 2/12/2014 3:09 AM, Micha=B3 G=F3rny wrote: >> Dnia 2014-02-11, o godz. 19:33:06 Chris Reffett >> napisa=B3(a): >> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 02/11/2014 06:13 PM, Gilles Dartiguelongue wrote: >>>>> Unfortunately, the concurrent nature of gtk2/gtk3 has >>>>> resulted in packages that may support either or both the >>>>> toolkits. To handle this, a few developers have introduced >>>>> the "gtk3" useflag, that prefers gtk3 over gtk2 when both >>>>> toolkit versions are supported. At this point, the Gnome >>>>> team highly recommends prefering gtk3 if possible, skipping >>>>> the useflag altogether. [1] >>>> >>>> Wrong, as is written in policy whether to prefer gtk2 or 3 is >>>> up to the maintainer of the package. We point people to the >>>> fact that upstream says gtk2 is a dead end and support will >>>> stop (if not in fact already stopped) in the near future. >>>> >>>> We also recommend to have maintainers support slots for their >>>> libs where possible considering man-power and to only choose >>>> one toolkit for applications considering where upstream >>>> development is going and maturity of the port, and again, this >>>> is up to package maintainers. >>> This doesn't make sense to me at all. I can't see why slotted >>> libraries can't just use USE flags to specify what toolkit >>> they're built against, just like any other package in the tree >>> (so, for example, a package that needs webkit-gtk built against >>> gtk3 would depend on webkit-gtk[gtk3] instead of webkit-gtk:3). >>> I'm well aware that there could be limitations I'm unaware of >>> (maybe the package only can build one at a time?), but this is >>> how it looks to me. By switching to versioned gtk flags, this >>> kills two birds with one stone: it makes it obvious to the end >>> user which version they're trying to build their package >>> against, and it gets rid of the need for (ab)using revision >>> numbers to implement slots like that. >> >> Except when you end up rebuilding the huge thing twice. Or trying >> to live with binpackages -- the thing that most Gentoo developers >> don't care about at all. They just love their precious USE flags >> so much they'd shove them everywhere for the sake of it. >> > > You'll have to build it twice anyway, this just splits it into two > separate packages, and I suspect that the times where you will have to > rebuild are when a package needs webkit-gtk to support another toolkit > (which should happen only once), and when you upgrade (in which case > you would be updating them separately anyway). After talking to Chris on IRC, I think we've made progress. I claim that there's a fundamental distinction between USE flags controlling how the binaries are built and controlling *which* binaries are built. I think that the use of SLOTs here is perfectly reasonable, since webkit-gtk installs different libraries (not just the same library with different build options) in the two slots. There's apparently some disdain for using the -r200/-r300 versioning to control the slots, but I think if we want to clean that up we should look at modifying PMS to allow something cleaner.