From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 46AD4138010 for ; Tue, 18 Sep 2012 09:43:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DC32121C0EA; Tue, 18 Sep 2012 09:42:38 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 6401521C0E7 for ; Tue, 18 Sep 2012 09:41:44 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so11832892pbb.40 for ; Tue, 18 Sep 2012 02:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=vvoxVvdZVCX0z1/Zf9MRlNj6wktlQQItBFvXvrXKdwE=; b=buRYX40kapu3mipJHIlJVGPArOUPyH5Qlb4imRHny0xnLcb+h+UYGyGT9F0HtdliA4 NUJgdZI0CgpneJZqqa3NsDiPp6w550/4qcD9wampohedqH7VPTiNh97/amrjCPxfD8im 7wdLfDqMeK9QCi0BU+bdRehSPo+E1wPOmnyUrXrvabZRga1/iuOuhEZIDahEV1vYAKdv TVBeFwnAme77m4WIDhZ1BTHebSSBNypOih9KoVfo0KzLsVubt/B/+AP+y448DLGqJeOe 5w1RNAqPjiexEjIXMo07tWHEQRD/ZMsJSK2uHHNMrVED6koDDMEyxvzbSGy16Yw7tnro 3sdw== Received: by 10.68.224.70 with SMTP id ra6mr428570pbc.11.1347961303751; Tue, 18 Sep 2012 02:41:43 -0700 (PDT) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id sr3sm8377590pbc.44.2012.09.18.02.41.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 02:41:42 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Tue, 18 Sep 2012 02:41:54 -0700 Date: Tue, 18 Sep 2012 02:41:54 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal Message-ID: <20120918094154.GC5384@localhost> References: <20120916135211.GC23030@localhost> <50581930.7030307@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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50581930.7030307@gentoo.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 946cad4b-f358-4003-a429-93fe9efaf8c2 X-Archives-Hash: 275eacc81d3388c40c8ebd1826f18a0c On Tue, Sep 18, 2012 at 08:48:16AM +0200, hasufell wrote: > I am unsure if that does or could solve the problem why GLEP 62 was > created, meaning... would enabling the "foo" useflag after the package > has been emerged trigger a remerge in the following example? > > DEPENDENCIES=" > dep:run? ( > foo? ( dev-libs/foobar ) > )" Just transfering over the discussion from IRC, tbh hadn't thought about it till you mentioned it since it has some potential flaws that aren't necessarily recoverable. Specifically, what happens if to enable dev-libs/foobar support, something has to be done at build time? Think about a systemd use flag, where the script just installs some configuration for systemd; that's not toggable. It's not obvious till you trace the implications through, but w/ those issues what you wind up with at that point is trying to classify use flags, ala glep62; see the past complete-ass-ripping of that proposal for why it doesn't fly. Just adding another; ebuild devs are completely up shit creek if the flag induces a build time effect in one spot, and controls optional deps in another section of the dep tree. If someone sees a way to make that work, have at it, although to be clear any such notion I'm intentionally leaving out of my proposal since I don't see a way to do it without an explicit dep labeling. ~harring