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 C5D3B139085 for ; Fri, 27 Jan 2017 08:32:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7FB8D234040; Fri, 27 Jan 2017 08:32:29 +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 285BF21C03E for ; Fri, 27 Jan 2017 08:32:29 +0000 (UTC) Received: from gentoo.org (unknown [IPv6:2001:984:48cf:64:a0fa:d6f7:16ca:ed56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: grobian) by smtp.gentoo.org (Postfix) with ESMTPSA id 8A0993413C3 for ; Fri, 27 Jan 2017 08:32:27 +0000 (UTC) Date: Fri, 27 Jan 2017 09:32:23 +0100 From: Fabian Groffen To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] berkdb and gdbm in global USE defaults Message-ID: <20170127083223.GK42019@gentoo.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <1485503640.22895.2.camel@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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QxIEt88oQPsT6QmF" Content-Disposition: inline In-Reply-To: <1485503640.22895.2.camel@gentoo.org> User-Agent: Mutt/1.7.2 (Darwin 16.4.0, VIM - Vi IMproved 8.0) Organization: Gentoo Foundation, Inc. X-Archives-Salt: e8411c7a-cdf7-4404-9ec0-8cf2427bb1db X-Archives-Hash: 451a4ee2ef2982121e9717d5d1c8b77e --QxIEt88oQPsT6QmF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. You mention REQUIRED_USE should be used sparingly, I think I see your reasoning, but if so, then why did we add it in the first place? Since the ebuild will only use one of the db backends, when multiple are selected, the package manager will falsely think both are in use (and trigger rebuilds, etc.). Isn't the point to express the actual situation as correctly as possible for the PM to do a better job? I also like the ebuild being way less convoluted, but I can overcome that is necessary. I'm interested to hear how other people feel about this. Thanks, Fabian On 27-01-2017 09:54:00 +0200, 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. >=20 > 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. > Though I guess this is a little bit more problematic when that DB is > long living, but I think it should still work good enough with this > guideline. >=20 > Then there is no need to think about what is enabled globally or not. > Point being, use REQUIRED_USE sparingly, and rarely a good idea to > block things with common global USE flags, or demand a local USE flag > based on a default enabled global USE flag without locally USE > defaulting that global flag too - and other such cases. >=20 > I'd talk to the maintainer(s) of such package(s) via bugzilla or other > means and discuss such REQUIRED_USE potential overuse. >=20 > > Looking through our profiles, I see we have both berkdb and gdbm > > enabled "globally". > >=20 > > 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" > >=20 > > Is there any reason to have these USE flags enabled globally? > >=20 > > These USE seem pretty package-specific in scope. On my system, they > > are used by around a dozen of 1000+ installed packages. I think it > > might make sense to migrate them to appropriate IUSE defaults, or > > leave them disabled where they do not provide critical functionality. >=20 >=20 --=20 Fabian Groffen Gentoo on a different level --QxIEt88oQPsT6QmF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iF0EAREKAB0WIQSDHIpHdkhfn9Ptmh5fdfYHxcdOiQUCWIsFlwAKCRBfdfYHxcdO iQvbAJ9bKmqEEhTIO5RJsFHAQhWwPHPyGQCeNr88KQia4Ee6TXvppAfLyBYCJK4= =qPa/ -----END PGP SIGNATURE----- --QxIEt88oQPsT6QmF--