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 995FF138CEF for ; Wed, 12 Feb 2014 09:14:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 034E1E0CCF; Wed, 12 Feb 2014 09:14:38 +0000 (UTC) Received: from baptiste.telenet-ops.be (baptiste.telenet-ops.be [195.130.132.51]) by pigeon.gentoo.org (Postfix) with ESMTP id D3917E0CB5 for ; Wed, 12 Feb 2014 09:14:36 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by baptiste.telenet-ops.be with bizsmtp id RMEb1n00j2khLEN01MEbG2; Wed, 12 Feb 2014 10:14:36 +0100 Date: Wed, 12 Feb 2014 10:14:26 +0100 From: Tom Wijsman To: mgorny@gentoo.org Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493) Message-ID: <20140212101426.383e46bc@TOMWIJ-GENTOO> In-Reply-To: <20140212090559.24aa64b5@pomiot.lan> References: <20140211223913.GB26141@fury> <20140212090559.24aa64b5@pomiot.lan> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/VC7itjp+SZ0vkz4MJR_qw6s"; protocol="application/pgp-signature" X-Archives-Salt: d496fbf5-22df-484f-b7ec-706541bda730 X-Archives-Hash: 4fb4097f412b235a0dd5ac39b3bf00d7 --Sig_/VC7itjp+SZ0vkz4MJR_qw6s Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 12 Feb 2014 09:05:59 +0100 Micha=C5=82 G=C3=B3rny wrote: > Dnia 2014-02-12, o godz. 00:39:14 > Alex Alexander napisa=C5=82(a): >=20 > > Some developers choose to follow the Gnome team's highlights, while > > others choose to go their own way. The QA team would like to > > establish a guideline that solves this problem in the best way > > possible. >=20 > First of all, I think that the policy on a flag related to GTK+ should > be set by the GTK+ maintainer, that is the GNOME team, and not > directly by QA. The GNOME team has already made a recommendation on this; and feel free to correct me, but I think they internally regard it as a policy the GNOME team itself has to apply. > If people dislike the policy set by GNOME, they can appeal to QA, > sure. This is what indirectly happens here; hasufell brought this up to us, as people are closing bugs blocking below tracker as RESOLVED WONTFIX: https://bugs.gentoo.org/show_bug.cgi?id=3D420493 An overview of the bugs blocking this tracker: https://bugs.gentoo.org/buglist.cgi?quicksearch=3DALL%20blocked%3A420493 > But IMO afterwards QA should either give their blessing to the > current GNOME policy or tell GNOME to change the policy, not step in > front of them with a 'higher instance override'. We've brought leio early into the discussion during the QA team meeting; as it currently stands, I think this is still a recommendation which makes it easier for people to object it. We've planned to bring this out to the mailing list (as wired did), as well as clarify the objections to it; in an attempt to listen and then discuss and work with the GNOME team on making this work for everyone. > > During our discussion, it was pointed out that keeping a generic > > USE=3D"gtk" is sub-optimal. The non-straightforward nature of new > > toolkit versions makes transitioning from one to the other a slow, > > tedius process and we think that a non-versioned USE flag makes > > things even worse. >=20 > How does the flag exactly do that? I don't seem to get the point > in that paragraph. What do we think the flag does? There are multiple ways to interpret "gtk - Add support for x11-libs/gtk+ (The GIMP Toolkit)" if you want to; and depending on that, there are underlying difficulties that pop up. Does it cover one slot or all slots? If it covers one slot, should it be named after that slot instead? If it covers multiple slots, quoting leio: Why don't we just rename it to USE=3D"gui"? Other people more acknowledged with that can probably explain it more well, but realistically the USE flag description should explain this more clear such that we don't need to explain it; now, consider this: Why is there no USE=3D"qt" for Qt? Why do we not need it there? > > To achieve this, version 3 of gtk should always be enabled by > > USE=3D"gtk3". At some point in the future, when gtk2 consumers reach > > zero, we will retire "gtk" for good. Then, if some day gtk4 comes > > around, we will be able to introduce support for it in the tree by > > simply adding USE=3D"gtk4", without having to re-structure half the > > tree. >=20 > This goes exactly against the policy that is being established e.g. > for USE=3Dssl. If QA is really supposed to set a policy here, it should > set a generic policy for all those cases. >=20 > USE flags should represent *features*, not tools used to implement > them. If users want SSL support in an application, they want to set > USE=3Dssl and stop caring. Not look through all the USE flags in case > application used USE=3Dopenssl, USE=3Dgnutls, USE=3Dpolarssl etc. for it. Exactly, I think this backs up the USE=3D"gui" idea above. [TL;DR: Skip the next two paragraphs, we're agreeing on that; I just left it in for if anyone wants to read it for furtherer understanding.] As for the versioned USE=3D"gtk3", ...; I'm wondering how the user would then specify what to build for, or even worse: If a package depends on gtk+ without a SLOT and was build against gtk3, then the user wants to support gtk4 as well but hold on to gtk3 until all his packages work with gtk4, how would you reflect that in the ebuild? I see USE=3D"gtk" --> USE=3D"gui" as a good idea; however, for a reason like the above where control as to which GTK version is supported (benefits changed USE flag rebuilds) is needed by the user are affected if we decide to do something about the versioned USE=3D"gtk3", ... > Multiple USE flags make sense when there's support for multiple > toolkits that works and is maintained, and the user may reasonably > want to switch between them. But then, the extra USE flags for toolkit > switching should be introduced with keeping USE=3Dssl as the generic > on/off switch and the specific flags an optional implementation switch > for power users. >=20 > In the end, GTK+ is much the same. You want GTK+ GUI, you enable > USE=3Dgtk. You need specific switching between 2 and 3, assuming it is > *reasonable and well supported*, you can use extra USE=3Dgtk2 or > USE=3Dgtk3. Sorry; should have read further before writing my previous quote response, there's agreement here to a large extent as you can see by the previous two paragraphs. > This generally works, and causes issues mostly to complainers alike > 'I dislike this, I want to be able to easily mask it all'. I don't > think there's a point messing up the general case for the sake of > complainers that will either end up enabling USE=3Dgtk3 anyway at some > point or end up without a GUI. >=20 > That said, I'm all for killing most of USE=3Dgtk, USE=3Dwxwidgets, USE=3D= qt* > occurrences with a generic USE=3Dgui following the earlier principle. This last sentence (especially the * on qt) makes me wonder if we fully agree though; as put out in the two paragraphs I told you to skip, this takes a bit of control away from the user which some users might want. Also seems you are already aware of USE=3D"gui" (or came up with it too). > If user installs an application and wants a GUI for it, shklee > shouldn't have to care whether it's GTK+, wxWidgets or Qt. Gentoo > should be a distribution friendly to all toolkits, people who collect > applications specific to a single toolkit belong in {,k,x}ubuntu. > Then, the special USE flags make sense for fine-picking one > of the toolkits when multiple are supported. Yes; in this context, users can mask what they want to avoid. --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/VC7itjp+SZ0vkz4MJR_qw6s Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJS+zt2AAoJEPWZc8roOL/QfVYIAIHkECc2tGmFleV9Bi+wxn82 rZrYDNUCPiXcNH0bDbelbsuznNUpACsl2lHKG0pAbuNRaVInUz8N8HphXMnrO0AB tt2ZhZa89DBtyLQJrBXEdpWTbO3IbloG8ynjfrF7O/VMefzvcN+JXo5m1FgwCuBS mD2WmsDejcDIeWT0jhZUskU6jEPbpVi90D+jBNknkNpvwbqIfOVajibME7rs0SeD 9JpPiw7IbhihWRX6ZyAeNzTps2dFwVDN83BqKVPy/KRvFlS1RuzpdkW+9f4hc6yO QnZ93+Bb0g7HXTVHrUp4byFQLTfOzRszcQQMgYEw4lkKr36w7cxtvtNwBFHr5o8= =6yhP -----END PGP SIGNATURE----- --Sig_/VC7itjp+SZ0vkz4MJR_qw6s--