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 799DA138010 for ; Mon, 17 Sep 2012 14:23:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9DFBEE002C; Mon, 17 Sep 2012 14:23:21 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id C369521C013 for ; Mon, 17 Sep 2012 14:22:29 +0000 (UTC) Received: by bkwj4 with SMTP id j4so2517863bkw.40 for ; Mon, 17 Sep 2012 07:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PyH3I0E2HOCxYzdtxVqP1vux0fGVeoF7d2v3Jn14Sc8=; b=Gkmol586LnFL31ruu0Mu1ypT0YUgo4oQ/ddZfy3ZsVKlUGLBb9ep2zjzMoN8Qy35rF RFJeCRnYpH3J6AOSSsnBmh9wsc/vgnBhRXD4TxLNUGylMMEoFD+Q0yyu/u1b/QKwm6un 8qBr+JPytziUtEnfTZ4LmNGCCJ4tdzDEJNNOQViYmsRCDDTTdW2YQF9zUulknpw+PUsc MiLgMNx+oZK/iCSphqM3j9ZgKO1N7QioO2pYEh/aHa2Cat7QkAb3yH78rHiYDFl13QXJ SZR44TFl4HlSmA6TOcbuwFdLuR3as8yin2s0QqYUx2ctNZK5cNcBQXkDOKMwWdDLuS9W YhGQ== 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 Received: by 10.204.145.85 with SMTP id c21mr4119144bkv.46.1347891748840; Mon, 17 Sep 2012 07:22:28 -0700 (PDT) Received: by 10.204.112.211 with HTTP; Mon, 17 Sep 2012 07:22:28 -0700 (PDT) In-Reply-To: References: <20120916135211.GC23030@localhost> <20120917030821.GA15027@localhost> <20120917134149.0bc8ab72@googlemail.com> Date: Mon, 17 Sep 2012 10:22:28 -0400 Message-ID: Subject: Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal From: Michael Mol To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: c1a4010e-160b-4462-b962-2d1553d8b32a X-Archives-Hash: 09eb1352abe639131370642387b38e74 On Mon, Sep 17, 2012 at 9:48 AM, Ben de Groot wrote: > On 17 September 2012 20:41, Ciaran McCreesh > wrote: >> On Mon, 17 Sep 2012 19:49:12 +0800 >> Ben de Groot wrote: >>> Or, even easier and more straightforward: just keep using *DEPEND. The >>> case hasn't been made yet why we need to change that in the first >>> place. >> >> We're looking at something like eight *DEPEND variables in EAPI 6, with >> considerable overlap between them all. > > And like now, in the great majority of cases, only two or three will be used. > The enormous cost of moving to a different system (or the folly of using > two systems in parallel) is not worth the slight benefit of a more cosmetic > handling of the few cases where a few more *DEPEND variables would be > needed and/or there is some overlap to be dealt with. As someone who's been reading these threads, but hasn't actually written any ebuilds from scratch, I'd like to offer my perspective as a well-intentioned beginner: On labels: The labels, to me, appeared largely more readable (and less formidable a syntax to read and write as a human) than the foo? ( bar/baz ) syntax...until someone demonstrated a distinction between depends and dependency types. I hadn't even noticed a distinction between the two, until that point was raised. While I like the labels (to me, they feel similar to Makefiles or C switch statements), a clearer distinction between dependencies and dependency types would be nice. On unified DEPENDS vs *DEPEND: It seems to me that at a code level, there's no real semantic difference. Since they both parse out losslessly to the same abstract thing, you could serialize that abstract thing back out into either format. Given most cases will be simple, you could even serialize it away into something not bash-based, if desired. All this means, to me, that the behavior of the two under the hood is essentially irrelevant, and any bugs in complex implementation could be caught with automated testing. I personally favor a singular 'DEPENDS', because 1) I feel it would lead to better-organized documentation (I'm looking for details about one var, rather than two or three vars--oh and then there's the other N *DEPENDS I may not even have heard of yet), and 2) I worry less about accidental namespace pollution in my make.conf file. Why do I worry about namespace pollution? Rather than using profiles, I have around 40-50 USE flags divided by category into varnames like SYS_USE_COMPRESION, and then I have a line that says USE="${SYS_USE_CPU} ${SYS_USE_COMPRESSION} ${SYS_USE_DONOTWANT} # etc" which coalesces it all. When I ran into a strange problem some time back, someone assisting me initially suspected that my SYS_USE_* vars might be conflicting with something internal to portage. Again, this isn't coming from a seasoned developer, this is coming from a well-intentioned beginner with very little time on his hands. -- :wq