From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id ED281139085 for ; Fri, 27 Jan 2017 12:01:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 694E7E0D1A; Fri, 27 Jan 2017 12:01:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1FFC3E0D14 for ; Fri, 27 Jan 2017 12:01:24 +0000 (UTC) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: djc) by smtp.gentoo.org (Postfix) with ESMTPSA id 1289034163E for ; Fri, 27 Jan 2017 12:01:23 +0000 (UTC) Received: by mail-it0-f45.google.com with SMTP id r185so54409130ita.0 for ; Fri, 27 Jan 2017 04:01:23 -0800 (PST) X-Gm-Message-State: AIkVDXKyXdzIFL8dCjb3u8OVctpkmnS3Y62WmFxhYfuaIjDs84t+Qo5OvHDpjK39Ofk6UF/HQhdMU66k6TVpww== X-Received: by 10.36.241.15 with SMTP id c15mr2655156iti.77.1485518480831; Fri, 27 Jan 2017 04:01:20 -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.107.9.100 with HTTP; Fri, 27 Jan 2017 04:01:00 -0800 (PST) In-Reply-To: <20170127083223.GK42019@gentoo.org> References: <1485503640.22895.2.camel@gentoo.org> <20170127083223.GK42019@gentoo.org> From: Dirkjan Ochtman Date: Fri, 27 Jan 2017 13:01:00 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [gentoo-dev] berkdb and gdbm in global USE defaults To: Gentoo Development Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: f8118ef9-44bb-4c00-8ee0-ee35bc2ceab8 X-Archives-Hash: a8928c1c2da310993919a37e9a64d98c On Fri, Jan 27, 2017 at 4:33 AM, Mike Gilbert wrote: > Looking through our profiles, I see we have both berkdb and gdbm > enabled "globally". > > default/linux/make.defaults:USE=3D"berkdb crypt ipv6 ncurses nls pam > readline ssl tcpd zlib" > releases/make.defaults:USE=3D"acl gdbm nptl unicode" > > Is there any reason to have these USE flags enabled globally? Good question... I already disable them, I think, as it doesn't really make sense from my perspective to enable them globally. I think letting packages set their own defaults with IUSE would probably be a better solution. On Fri, Jan 27, 2017 at 8:54 AM, Mart Raudsepp wrote: > =C3=9Chel kenal p=C3=A4eval, N, 26.01.2017 kell 22:33, kirjutas Mike Gilb= ert: >> I recently ran into a REQUIRED_USE constraint that required I select >> between berkdb and gdbm for an email client. > > There shouldn't be a REQUIRED_USE constraint that forces you to select > one or the other. The maintainer should be giving the choice of both, > but if only one can be chosen, the maintainer should make the choice > for you by preferring one of them. Likely gdbm, given berkdb licensing > saga. I'm not sure this makes sense to me. If the package will actually select one implementation out of a set, it makes sense to me that the maintainer for that package makes that choice explicit towards the user. In that case, setting REQUIRED_USE accordingly seems exactly right. The maintainer should set a good default, but if the user's USE settings are inconclusive in getting to the choice of implementation, it's better to whine explicitly than try to guess implicitly what the user wanted. On Fri, Jan 27, 2017 at 9:32 AM, Fabian Groffen wrote: > Replying here because I think said email client is the one I recently > added REQUIRED_USE constraints for. > > Reason I added it is because it greatly simplified the ebuild: it's not > just bdb and gdbm, but also tokyocabinet, qdbm and lmdb, with as result > a lot of if-else-casing which implemented the implicit defaults before. > I didn't realise changing this to REQUIRED_USE resulted in a conflict on > default profiles, because I (obviously) have a package.use entry for the > package. I don't see Mike saying you got it wrong here. Reading your email, I think you did the right thing. Cheers, Dirkjan