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 58955138010 for ; Sat, 15 Sep 2012 20:34:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2C23E21C01C; Sat, 15 Sep 2012 20:34:08 +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 5F5C3E04C2 for ; Sat, 15 Sep 2012 20:33:14 +0000 (UTC) Received: by dadg9 with SMTP id g9so358792dad.40 for ; Sat, 15 Sep 2012 13:33:13 -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=DiZOAvwvXBpndUL/kcFhZ4Eu7TZxeC+wLjksKApAhsM=; b=XipE39aXWWVK9nk7ogGy8XQbnBkcNWE3ZFA6ChbqAp5J7qsSTpGnKECtzHpKVKun5g gsFm512oJM36WHAEwaTUZEkLx1tr+rh3hS50L103h3pUKRXb02iikgOd4xgtkuPi40Lz WycO9/9Jhr+Q0xP2qk84ReZ1qA7mQM54yIKaBZX5IVU7xbdIhqAvQqRo3PTmIbUUoUUp sc0iHsbf4z13FH++5dPgSCIuBZPjv7pkcnnS2IdPNwzSgriSY5+ygvqVRVwhNWHCaCM9 8O/FFqDFVERn7hSXlhomfeXTETCahRqsXjpZ/DNSNHR0Vj/SkE2eS5Yj7W6XjVGMGWVK kvnw== Received: by 10.66.89.37 with SMTP id bl5mr10635752pab.55.1347741193640; Sat, 15 Sep 2012 13:33:13 -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 qf4sm3581251pbc.1.2012.09.15.13.33.06 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Sep 2012 13:33:10 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Sat, 15 Sep 2012 13:33:18 -0700 Date: Sat, 15 Sep 2012 13:33:18 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Cc: axs@gentoo.org Subject: Re: [gentoo-dev] Unified DEPENDENCIES concept Message-ID: <20120915203318.GH28593@localhost> References: <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> <20120913221732.GE28593@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: b2d5d2e3-89f1-4a6c-8f38-3c321104e964 X-Archives-Hash: b23edb77bcf3ad3ca4224cb87733c017 On Sat, Sep 15, 2012 at 11:06:01PM +1200, Kent Fredric wrote: > On 14 September 2012 10:17, Brian Harring wrote: > >> 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 > > > > > Sure, but at least this makes it a viable proof-of-concept without > needing all the different PM's to implement the new spec first, and > due to not being EAPI bound when done this way, means you can just do > it and have it work both now and in the future. > > And because of this "experimental" nature, you don't have to do *ALL* > the parsing in bash, you could make the eclass use some external code > to parse it and spit it out, and simply have the eclass depend on that > external program regardless. > > I agree that long term, a Unified DEPENDENCIES implementation is the > way forward, but if you want to convince people, having something > which has been demonstrated and tested in a real world setting goes a > long way. Honestly, QA would be well within their rights to kick anyone who did this, *hard* in the shins. I understand your notion- specifically proof of concept, show the data, etc; I just think you've still got inverted, too focused on trying to do it in bash. To demonstrate the gain of this, we basically take the existing tree's deps, and re-render it into a unified DEPENDENCIES form. As for adding support to a PM, if we use the use conditional proposal of mine, it's bloody simple- the PM already supports it, we just need some minor USE_EXPAND adjustments. ~harring