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 40199139734 for ; Tue, 11 Aug 2015 13:30:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E479414267; Tue, 11 Aug 2015 13:30:51 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D6164141F3 for ; Tue, 11 Aug 2015 13:30:50 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZP9dg-0007JD-N9 for gentoo-dev@lists.gentoo.org; Tue, 11 Aug 2015 15:30:48 +0200 Received: from ppp118-209-133-158.lns20.mel8.internode.on.net ([118.209.133.158]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Aug 2015 15:30:48 +0200 Received: from kensington by ppp118-209-133-158.lns20.mel8.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Aug 2015 15:30:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Michael Palimaka Subject: [gentoo-dev] Re: useflag policies Date: Tue, 11 Aug 2015 23:30:31 +1000 Message-ID: References: <55C7AC24.2040503@gentoo.org> <55C9CA32.3060300@gentoo.org> <55C9F189.10102@gentoo.org> 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: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ppp118-209-133-158.lns20.mel8.internode.on.net X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 In-Reply-To: <55C9F189.10102@gentoo.org> X-Archives-Salt: 7cde8b81-5fc7-4c62-ac4d-e5fff6d085aa X-Archives-Hash: 1422add40b11a34d2fc3f4b4644f42c9 On 11/08/15 22:58, Sergey Popov wrote: > 11.08.2015 15:30, Michael Palimaka пишет: >> On 11/08/15 20:10, Sergey Popov wrote: >>> Err, i have read the whole thread and still does not get a point, why i >>> am wrong. >> >> You clearly have not. The reasoning behind Qt team's policy is described >> on the page and has been reiterated on this list. You are undermining >> what little confidence there is in the QA team by making decisions with >> no consultation about problems you do not understand. >> >>> It's old battle like we have beforce with "gtk" meaning "any versions of >>> GTK flag". This behaviour should be killed with fire. >>> >>> Let's me reiterate some of the cases: >>> >>> 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can >>> be chosen, but not both. >>> >>> Fix this with REQUIRED_USE, do not enable any of Qt flags by default >> >> Problem: this requires manual intervention if the user has both qt4 and >> qt5 USE flags enabled. >> > > User choice of using USE flags is NOT a problem I invite you to reproduce the problem yourself then make the judgement. Using REQUIRED_USE like this makes the affected packages unusable. >>> >>> 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is >>> required, but not both >>> >>> Same thing here, different REQUIRED_USE operator. But - enable one of >>> the flags by default to ease life of users. >> >> Problem: this requires manual intervention if the user has both qt4 and >> qt5 USE flags enabled. > > Same here > >>> >>> 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such >>> package even exists?) >>> >>> Do not use REQUIRED_USE here, not needed. >>> >>> Now, please tell me, where am i wrong? >>> >> >> The problem is manual intervention is required if the user has both qt4 >> and qt5 USE flags enabled - and this is a common configuration. It is >> not acceptable to make a user manually add numerous package.use entries >> when all they want to do is install KDE. > > And here > >> I agree Qt's policy is not a perfect solution, but in the absence of >> some feature allowing a preference to be set when there is a conflict >> it's the best we've got. >> > > If you want to go this way, then please provide helper functions in > eclasses to set dependencies properly for all common use cases. That > will ease life both of developers and users. > > Leaving constructing of dependencies to developers in all cases will > cause only pain in your solution. > > Look at the example with berkdb/gdbm, that i have posted recently. > > If both of flags are not set - we stick to default. > Should this be set in EVERY ebuild explicitly? > > Maybe provide some sugar like $(qt_use_default qtgui 5), where > qt_use_default is the name of function, qtgui is the package and 5 is > the slot for default choice, where either BOTH of flags(qt4, qt5) are > enabled or disabled How does this solve the REQUIRED_USE problem? Or is your only objection is that resulting dependency string is "too hard"? Don't forget that as a project with no special authority, Qt's policy remains a suggestion for the vast majority of maintainers. If someone wishes to provide support for only one Qt version or abuse their users with REQUIRED_USE they are still free to do so.