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 E3914138010 for ; Thu, 13 Sep 2012 22:18:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0CB20E0458; Thu, 13 Sep 2012 22:18:42 +0000 (UTC) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 0B581E05DB for ; Thu, 13 Sep 2012 22:17:30 +0000 (UTC) Received: by dadg9 with SMTP id g9so2279051dad.40 for ; Thu, 13 Sep 2012 15:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ZLsEDaEvf7c3iV8FwHVkI5AILcOR0NXtfpkIQmsTS74=; b=zaJ+cHqOlUP195aEh2du4/51qRrVjj5mUujpTdrtrEr2QOjbcdYD3pIQK6AdSC1dMt mW2oLyJDudv12uEV4QbPev3m0WWDD33LHC23TL4YtcERYyBcgh2Z3PQQIpy2kyegS8vs 2ezWN67kQUhPfmQrcyl8Lv4xrRH6EwDqbHgL8DC41d+dbKR1WRCiG/TEl9gaaQfXuJTg uBA8T9CXOPhTw742LEwloyjBRpKH1WDAGhdd6uV6BAQYCaAwCw0GOZw9l+nTw9cJQ0Ml Ck19N4cSGdu2aTTkzsR/cVf583bE87O7p7Ql9ZFRTriPP6SNqTlo/D5Lupd48JcmKeQl D/vw== Received: by 10.66.83.129 with SMTP id q1mr1014178pay.4.1347574650078; Thu, 13 Sep 2012 15:17:30 -0700 (PDT) Received: from smtp.gmail.com:587 ([63.251.193.4]) by mx.google.com with ESMTPS id qb2sm13755101pbb.15.2012.09.13.15.17.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Sep 2012 15:17:29 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Thu, 13 Sep 2012 15:17:32 -0700 Date: Thu, 13 Sep 2012 15:17:32 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Cc: axs@gentoo.org Subject: Re: [gentoo-dev] Unified DEPENDENCIES concept Message-ID: <20120913221732.GE28593@localhost> References: <20120907124559.68a1b88d@googlemail.com> <20120907124641.0135693d@gentoo.org> <20120907180351.4e682fd5@pomiocik.lan> <20120907144025.06b3d1eb@gentoo.org> <20120907202103.671d98b1@pomiocik.lan> <20120907165948.2dbe3fdd@gentoo.org> <20120907221051.4a7a6bde@pomiocik.lan> <504A5599.7060506@gentoo.org> <20120911021617.GE8036@localhost> 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: User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: d196e6e4-7c8a-483a-9016-e598416990bc X-Archives-Hash: 12e3a748a8eabe167385b356c8eaa5ca On Fri, Sep 14, 2012 at 07:18:54AM +1200, Kent Fredric wrote: > On 11 September 2012 14:16, Brian Harring wrote: > > On Fri, Sep 07, 2012 at 04:14:17PM -0400, Ian Stakenvicius wrote: > >> Is there anything in particular in the spec/proposal for DEPENDENCIES > >> that would exclude the addition of individual "build: app-cat/myatom" > >> "run: app-cat/myatom" deps by an eclass or eclasses? I know the > >> "goal" here is to make things atom-centric, but I can't see an > >> implementation ever working of this that wouldn't permit the "pile-on" > >> of additional entries of different (or even the same) roles on > >> identical or near-identical atoms. > > > > They could be piled on; it would require each eclass to reset the > > label for safety reasons though; same goes for ebuilds frankly (or the > > PM would have to reset the context to build+run: each time through). > > > > Pardon if addressed elsewhere; this thread is a fucking mess... > > ~harring > > > Correct me if I'm wrong, but couldn't the entire proposition could be > implemented in an eclass, not needing the EAPI development cycle to be > tied up with it. > > All you need is something in bash that can parse DEPENDENCIES and > populate *DEPEND , and the underlying guts could be done in > practically any language without requiring PM specific > implementations. You've got it inverted; if any autopopulation is occuring, *DEPEND -> DEPENDENCIES is the sane form. While it definitely *is* possible to render DEPENDENCIES down into depend/rdepend (after all, the PM has to do exactly this for resolution), that does /not/ mean doing it in bash is a good idea. I'd really not want to try that using labels; using use conditionals ('dep:run,build? ( targets )') is frankly a bit easier imo, but still; why do so unless one likes pain? It doesn't actually gain us anything via missing the point of DEPENDENCIES. The point of unified DEPENDENCIES var (regardless of the form) is thus: 1) ability to specify common deps once, w/out having to use intermediate vars/copy-pasting/etc. Think COMMON_DEPEND, and this should make sense. 2) To shift to a form where adding new dependency targets is easy- whether it be sdepend, fdepend, tdepend, or hdepend (or ONE-RING-DEPEND to rule them all). This actually is rather important; for the average 95% case, devs won't actually have to pay much attention to those vars; but for those of us a bit further out (cross compilation, heavy parallelization, etc) those depend forms are becoming increasingly painful in their absense. Basically, having devs specify DEPENDENCIES in ebuilds, which then an eclass chunks out into DEPEND/RDEPEND misses the point of this; it's doable, it's just not particularly sane imo. The other way around, having *DEPEND automatically be collapsed into DEPENDENCIES, however is very sane- it makes transition/compatibilty for devs bloody simple, while structuring it so we can do further enhancements. ~harring