From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NvwBd-0004zR-F9 for garchives@archives.gentoo.org; Sun, 28 Mar 2010 17:22:10 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4ABACE0954; Sun, 28 Mar 2010 17:22:04 +0000 (UTC) Received: from qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.145]) by pigeon.gentoo.org (Postfix) with ESMTP id 71EFBE0903 for ; Sun, 28 Mar 2010 17:21:50 +0000 (UTC) Received: by qw-out-1920.google.com with SMTP id 5so1402104qwf.10 for ; Sun, 28 Mar 2010 10:21:50 -0700 (PDT) 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 Sender: antarus@scriptkitty.com Received: by 10.229.46.11 with HTTP; Sun, 28 Mar 2010 10:21:49 -0700 (PDT) In-Reply-To: References: <1269455454.31227.12.camel@lillen> <4BAE19DE.70206@gentoo.org> Date: Sun, 28 Mar 2010 10:21:49 -0700 X-Google-Sender-Auth: 48d7a65e42c9a4c1 Received: by 10.229.227.83 with SMTP id iz19mr191999qcb.44.1269796909809; Sun, 28 Mar 2010 10:21:49 -0700 (PDT) Message-ID: Subject: Re: [gentoo-dev] when to use a function and an implementation use flag. From: Alec Warner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: b626cb48-a065-415d-8400-638dadd6586f X-Archives-Hash: 3496de83f574407515cda34173c716df On Sat, Mar 27, 2010 at 11:06 PM, Doug Goldstein wrote: > On Sat, Mar 27, 2010 at 9:44 AM, Petteri R=C3=A4ty wrote: >> On 03/24/2010 08:30 PM, Peter Hjalmarsson wrote: >> >>> For qemu-kvm the problem is that there is only one implementation (i.e. >>> gnutls), and if I want to have ssl support I have to enable gnutls for >>> this package. >> >> In this case the ebuild should have only ssl use flag. >> >>> When I wrote a bug about this I got a rather short reply from maintaine= r >>> about pointing me to the policy about this. >> >> Where did he point you to? > > I didn't point him anywhere. I merely asked him for a policy on this. > Because senseless changes in USE flags will require my 9 VM servers > will need to be tweaked around for a pointless USE flag change and I > don't need administrative burden for the sake of administrative > burden. I have concerns with this which I will attempt to summarize below. 1) Traditional binary distributions have releases that take users over these changes (dist-upgrade and similar processes.) 2) Gentoo has no releases, so 'annoying administrative changes' are certainly more challenging, because it is difficult to apply them to new machines and not old ones. 3) Cleanup changes such as the one proposed are good for the health of Gentoo. Consistency in flags actually makes it *easier* for users to configure their systems. Consistency in ebuild behavior makes it *easier* developers to maintain ebuilds. 4) Not making changes because they may affect existing systems is crap. It holds the distribution back because everyone will always pull this card out to veto major changes. It would be interesting if we could make these changes less painful: 1) For this change, attempt to detect how users are using these flags and migrate them to the new system. This will likely be easy for the 80% case (/etc/portage/...) and hard for the 20% case (cross-compiles, and other odd things involving ROOT.) 2) Defer changes like this to some kind of release date. Write down what you want to do somewhere. At the prescribed time (once a [month, year, quarter?]) apply all the changes to the tree and release GLEP 42 news items, changelogs, webpage stuff, forums posts, etc. 3) other crap I haven't thought of. > >> >>> So I have a question: >>> Is there no policy about this? >> >> The policy is that USE=3D"ssl" controls whether to enable ssl support in >> general. Then the specific use flags like gnutls and openssl control >> what implementation to use if the package supports multiple. > > Again, this policy is stated but no one can point me to anything. The > closest thing to a "policy" is you sending a follow up e-mail to the > dev list to make this a policy. > > -- > Doug Goldstein > >