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 6A8CC139085 for ; Thu, 2 Feb 2017 18:02:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E135921C102; Thu, 2 Feb 2017 18:01:54 +0000 (UTC) Received: from mail-yb0-x241.google.com (mail-yb0-x241.google.com [IPv6:2607:f8b0:4002:c09::241]) (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 9453F21C099 for ; Thu, 2 Feb 2017 18:01:54 +0000 (UTC) Received: by mail-yb0-x241.google.com with SMTP id w194so1019087ybe.1 for ; Thu, 02 Feb 2017 10:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=u/bGfhN1FD3FoyBe2/lPK9M+ubZtJgJXRdT267ry5LY=; b=Plu3w7YrZHpirzrfpmM3e8JkHHIK0vuD1dwQxelT0/3gpF+0LhdBCOOwXPGXCXdAx3 Tay+R66wBNttsbx2/LfiJIeH3fpphEFMzg9CZY1WQ3MwWsvh2kcwiDb6AJqulW+8nMg+ TxbuQoCY74MQ582IHug1D/zxuywTY3B1actQWA1jnV9Cw7QxCgI/iYHQkWNPGCS9JWJv +9yQhQ1Q3bXmsPvJ8D47GSHZHcHeg/MFtVlqS6PQidCuQivAkb55MG1P7W9DTNdaIvGJ OSjDUa31XN0w6nXRZLIpJ6zkhk+3Duvfzk/S43ZWS8PKFZBiF06vdQaU4MCn+wDfo36/ UlNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=u/bGfhN1FD3FoyBe2/lPK9M+ubZtJgJXRdT267ry5LY=; b=sxzIfv8HAL/jHQnEL5ZDBqgf4srKEe5o9aaMYKHRrbuwI2afJujuxmrj4OPbNZhzKG ZUyEUZnr0WMwO8g9Pm0gn0LhMs2AjR/VTcnk6D/9vMfMJrDMeT/7jeVCESDnzXemQ2PQ JLmJxt7RB/qk26DejtkVNfOb5l0BUe2QgnKEKLqaGCR3j+nnHT9smGQQ2PJjQOfcbM1R tyO0PVCbs4vaOuGB/68RQWRoXhw2TwQRLp+Y63QWkpYoAKUDqqvKdzP6hM94fDaaIOVd bWScXAdiPXQmdff3W4dlBd7A/J2pR6fQ5S6J8W/ZUudjReXiT4kURbxnsG7BHf13/NIi OODw== X-Gm-Message-State: AIkVDXI0pcvWxKvVjLVpzI8Pm2LXmHpCkxP0vCD3Zrt3CyHhFagJsL40YsXkyhZdhij3EEVGGCLwvdhS3xzwoA== X-Received: by 10.37.57.84 with SMTP id g81mr3113879yba.14.1486058513493; Thu, 02 Feb 2017 10:01:53 -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 Sender: freemanrich@gmail.com Received: by 10.13.239.193 with HTTP; Thu, 2 Feb 2017 10:01:52 -0800 (PST) In-Reply-To: <68433328-e9a2-03ec-bad7-c81a0d8f442c@gentoo.org> References: <3a32da5b-e7f8-c21d-a990-ffbedb2c958b@gentoo.org> <0b9e6324-9d41-e35f-d077-1496e0bac05d@gentoo.org> <68433328-e9a2-03ec-bad7-c81a0d8f442c@gentoo.org> From: Rich Freeman Date: Thu, 2 Feb 2017 13:01:52 -0500 X-Google-Sender-Auth: ZW0z79tHn_1LloscLEqcKD8xlm4 Message-ID: Subject: Re: [gentoo-dev] Guidelines for IUSE defaults To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 5898cbb2-aec8-4a85-940c-b68620d3d5e8 X-Archives-Hash: 480b7a1785a00f3aaa63bf1e5747c5cc On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky wrote: > > If (base == minimal), then all of the upstream defaults need to be added > to package.use for the upstream-defaults profile. That's bad, I'll go further and say that it is unacceptably bad. > but if > (base == upstream-defaults), then the important IUSE defaults need to be > copy/pasted from our ebuilds into the minimal profile. The latter is > more spiritually damning =) > So, I'll admit I've never been one that cared a great deal about minimalism so I appreciate that I may not be the best one to judge this, so let's go ahead and embrace your statement for the purpose of debate. Is there a better way we can have our cake and eat it too? I'll admit that a huge package.use on the minimal profile isn't a whole lot better than a huge package.use on all the other profiles. Do we need another form of syntax in individual ebuilds to try to separate out the various cases you cite? Does anybody care to actually suggest one? I still think that we shouldn't encourage users to lightly deviate from all the upstream defaults. There are of course legitimate reasons for doing so, and you and I can probably appreciate when we should do this, but for somebody starting out we're giving them a lot of rope to hang themselves with. It is like building a kernel answering no to the largest number of questions possible while still actually building something. I'd actually be curious as to what that kernel would even be capable of doing (there are a lot of fairly essential things you can turn off in the kernel). In the same way, we shouldn't be too quick to deviate from upstream defaults ourselves (#4 in your example), beyond actual integration work. I'll admit the current state is a bit of a compromise, but I don't think we should change it unless we're changing it to something significantly better. This is a pretty big-impact change. -- Rich