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 9EC3B139085 for ; Thu, 2 Feb 2017 17:18:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 24A01E0D72; Thu, 2 Feb 2017 17:18:48 +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 CDD1AE0CC2 for ; Thu, 2 Feb 2017 17:18:47 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id 532AA340DC7 for ; Thu, 2 Feb 2017 17:18:46 +0000 (UTC) Subject: Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults To: gentoo-dev@lists.gentoo.org References: <8c7e74ab-73d5-385f-c780-f7d936ce1027@gentoo.org> From: Michael Orlitzky Message-ID: Date: Thu, 2 Feb 2017 12:18:43 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: fe460523-0145-4164-b0f5-ab8ff9b066c0 X-Archives-Hash: f1234374b7edcc76598406be9e51f35a On 02/02/2017 12:06 PM, William L. Thomson Jr. wrote: > >> But more importantly, icedtea-bin was just one example that I had in >> mind. There are hundreds of others in the tree. > > Sure, but some packages themselves go against a minimalist approach due to > their own build requirements. You have to fight the package to make them > minimal and I am not sure the fight is worth it at times. > We agree on that. If making GTK optional for your package is too much trouble, then don't make it optional. The problem is only when the maintainer does make it optional, and then defaults it on in every profile using IUSE defaults. Most "give the user a typical system" USE defaults belong in a desktop or server profile, not in the base.