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 20C0C138010 for ; Sun, 30 Sep 2012 21:43:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 94B9AE0495; Sun, 30 Sep 2012 21:43:01 +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 8AC7821C08F; Sun, 30 Sep 2012 21:42:17 +0000 (UTC) Received: by pbcwz12 with SMTP id wz12so8044987pbc.40 for ; Sun, 30 Sep 2012 14:42:16 -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=STQ6PUo9BFIqbTTRfmsBh65J5d0nAxgZPIJ1A7EoGf0=; b=THI6HBAtTQE0d5CbvK/GVE1X1my5617rqqKb7+5qxcmQ4M1uI2sSGywaYMDcqK1Oku MzH3Nbi0abt1gsA3aZj92Eg86pwcC7HUkF+z1m5h9tXTocEFW6iSLYP7fmnLfhH8iPtK zcuUdaLAUhPolcaiGhfZRkUv5YifKmGDcJVmNqmxEkxBjD1QXHOPN9xpTvjipiIx0sBY p0wE5qUdtvxgpzvmaLO0BFdT6pS30iGXfBOK0adcp9Pe/idDbKKjCmelNvpxEwQ5KwiU UDqvgRGSfpS7+Rlo123YBsCGlmDf5XPu2q6z3Qc6/I9gAvemie/rpi+cSIL3vNxRcMiy JlHw== Received: by 10.66.79.166 with SMTP id k6mr32241310pax.44.1349041336599; Sun, 30 Sep 2012 14:42:16 -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 oe5sm9185510pbb.8.2012.09.30.14.42.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Sep 2012 14:42:15 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Sun, 30 Sep 2012 14:42:14 -0700 Date: Sun, 30 Sep 2012 14:42:14 -0700 From: Brian Harring To: Ciaran McCreesh Cc: gentoo-pms@lists.gentoo.org, gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal Message-ID: <20120930214214.GE2180@localhost> References: <20120916135211.GC23030@localhost> <20120916153949.05ab795a@googlemail.com> <20120916160528.GD23030@localhost> <20120916175921.4f01661a@googlemail.com> <20120925224614.GF26094@localhost> <20120929170509.63efef70@googlemail.com> <20120930201453.GC2180@localhost> <20120930213018.22fe16f3@googlemail.com> 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: <20120930213018.22fe16f3@googlemail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: b1bedda0-840a-438f-a56b-4f341ba49c09 X-Archives-Hash: ed50528a8f7c4f15209e832703819fde On Sun, Sep 30, 2012 at 09:30:18PM +0100, Ciaran McCreesh wrote: > On Sun, 30 Sep 2012 13:14:53 -0700 > Brian Harring wrote: > > > That's largely because there are a lot of former Gentoo developers > > > there who all said "oh, yeah, I forgot we could do it the other way" > > > when this was pointed out... > > > > I analyzed *all* exheres on git.exherbo. > > > > To be crystal clear, these include your packages. > > > > You yourself didn't use nested labels. So either the author of > > labels 'forgot' he could use it, or just didn't find the nesting > > actually useful. > > That's a rather disingenuous claim, considering how none of the > packages I maintain have any non-trivial dependencies... You could > equally well say that every single package I maintain makes use of > nested labels in every single place where they're relevant. Admittedly, that was a punch nearing the belt or a bit below; that said it's not disenguous. Reality is, our current form can handle deps generally fine- what you label as trivial is the vast majority- I argue effectively all. And I intentionally gave you a way to disprove that; find real world dependency examples to disprove it. > > So... real world usage removes one of the core arguments of labels, > > leaving it just as "it's a new syntax/aesthetically more pleasing" in > > comparison to dep:build? ( blah ) form. > > > > Not expecting you'll agree with that statement based on the facts of > > y'alls own repo... so if you're going to retort, bust out actual > > examples from eithe trees, where nesting would be preferable to the > > form people use now please; else just drop it (-your- own usage of > > labels disproves your claim; thus why I want actual examples now if > > that point will be debated any further). > > It's not just that it's more aesthetically pleasing. There are two > arguments favouring labels over use abuse. > > The first is that it doesn't have perverse behaviour associated with it > like your misappropriation of use conditionals does. If you put labels > deep in a tree, it's well defined. If you put your conditionals > anywhere except the top level, crazy stuff happens. This statement of yours however is fairly disenguous; label behaviour when nested suffers the same mental parsing oddity (wait, we're in build context, and this is test? Wtf happens there?). With 'use abuse' however, the situation is clear: dep:build,run? ( x? ( dep:test? ( blah ) foon ) monkeys ) Means that 'blah' target doesn't show up. Which is the *same* as what happens if someone did thus in our existing syntax: x? ( !x? ( blah ) ) Worth noting, you didn't ban that from exherbo; you left that to sort itself out, same as I'm doing for dep:blah flags. Were I punching below the belt, the word 'hypocritical' would likely be involved. > The second is that it starts the conceptual shift from "cat/pkg is a > build dep, and cat/pkg is a run dep" to "cat/pkg is a dep that is > required for build and run". Fairly weak argument at best; you're claiming that via labels, "contextually they know it's these deps" in comparison to via dep:build "contextually they know it's exposed only in build". Same difference. > > Bluntly, you want something that is academically possible, but > > pragmatically/realistically unneeded- meaning the gains are basically > > not there, but the costs most definitely are. > > No, I want something where things that are different look different. > Dependency types are nothing like use flags, so they shouldn't look the > same. I'll buy that argument, and to some degree- agree. I just view that as academic wankery without real world gain. So like I said, academically possible, but pragmatically/unrealistically unneded. No amount of arguing is going to dissuade me on that view either, although real world tree examples *might*- aka, stop talking, go analyzing. > > Either way, this is gentoo, we're talking about the ebuild format; > > just the same as everyone shredded mgorny's ass for proposing we > > mangle atom syntax w/out gain, and proposal you push for the deptree > > changing, has to have significant gains for changing the existing > > form; aesthetics at a cost aren't enough. > > The gain is that you have a syntax designed for what's being > represented, not an existing syntax abused to sort of (but not > quite, because it's still defined in terms of rendering down) do new > things. > > Really, all it takes to see that your syntax is bad is one tiny little > example: > > dep:build? ( dep:run? ( cat/pkg ) ) x? ( !x? ( cat/pkg ) ) Outlaw that in paludis/exherbo, and *perhaps* I'd listen to you. You're going into broken record mode; the fact people can do stupid shit if they're willingly trying to abuse the syntax isn't much of an argument- especially considering the PM can handle it either way, rendering it out to a noop. > There shouldn't be any need to add in a repoman check to catch that > kind of thing. The problem is entirely caused by bad syntax design. > Implementing labels is not difficult, and the extra cost is worth it to > get a good design. As I've said, there isn't a need for repoman checks. It's *suggested* since as I've stated, the underlying idiocy should be spotted in our existing deps. That said, repoman isn't necessary; such a construct solves itself via the deps dropping out; and before you try arguing that, your argument effectively would be based on "if someone specifies the deps wrong..." which means they're already up shit creek. Either way, pulling another "done with this thread" bit to wrap this up; you don't like the proposal, got it. In my proposal, I am addressing labels; will fold in your claims, but those claims basically are shit- however, if you *did* find a conflicting nested example that wasn't contrived, preferablly multiple, I'd like those examples so I can include them into the proposal (give labels a fair hand, basically). I don't think you're going to find any, let alone one; some artificially structured ones perhaps, but I'm not interested in those- I'm looking for real world deps where conflicting nested is the best form. Go find 'em; either way, moving on from the current discussion form (also known as "broken record mode"). cheers- ~harring