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 1C4E3138010 for ; Wed, 19 Sep 2012 07:14:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5A0FF21C079; Wed, 19 Sep 2012 07:13:34 +0000 (UTC) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 0D2FE21C067 for ; Wed, 19 Sep 2012 07:12:42 +0000 (UTC) Received: by vbbfc21 with SMTP id fc21so889766vbb.40 for ; Wed, 19 Sep 2012 00:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cEVtjIBTiv/3rDhF5AIiNfOmKcMxCexEWiz7c286u/c=; b=LQZUbnKkiMOJezXI4W9byC3u/IPnkr1yKqhITWigVnF/luZpweXoavY4pw8CNpntNc U53JDnoHuToSopjPtOTVXdjt3jNgwx7GqjZQ/xlFWFNAXROcBPxc5i70rIT5H74WgV+P w0TPNY4GjNPpJW00h1NeDrwXDczoY1b6eLZWYd+d2xHVGsmtPr1nq2aOD8/onM0aFS7e No5be8q7Sa1YkvZe4PIOoZ2unrRtX0GzIxlhfQYJPHc74QQH4HIDJCeqCUqnn5i7R/0Y l7Sab68vW8smKYqzTOX20nWgWymv0YzVfpPXemHbNOhAeQj22JiiDe8f/mjpG7HU6ino YsFw== 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.220.16.12 with SMTP id m12mr1500756vca.14.1348038762289; Wed, 19 Sep 2012 00:12:42 -0700 (PDT) Sender: yngwin@gmail.com Received: by 10.58.58.110 with HTTP; Wed, 19 Sep 2012 00:12:42 -0700 (PDT) In-Reply-To: References: <20120916135211.GC23030@localhost> <20120918102551.500ff19b@pomiocik.lan> <20120918092426.GA5384@localhost> <20568.16682.31115.233591@a1i15.kph.uni-mainz.de> <20120918110637.GF5384@localhost> <20568.25833.33593.344770@a1i15.kph.uni-mainz.de> Date: Wed, 19 Sep 2012 15:12:42 +0800 X-Google-Sender-Auth: flYXOi_LEtInXGVUsotGzilLwB4 Message-ID: Subject: Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal From: Ben de Groot To: Matt Turner Cc: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 2b408803-c41c-4dde-9ae6-cb72ad36f71a X-Archives-Hash: 9f0f408db5db8c6648c7ec04bbc7cde3 On 19 September 2012 14:01, Matt Turner wrote: > On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot wrote: >> On 19 September 2012 03:18, Alec Warner wrote: >>> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller wrote: >>>> Readability is more important, and there I still don't buy the >>>> argument that the new syntax is better, and that any gain would >>>> outweigh the cost of changing. After all, the existing variables for >>>> dependency specification won't disappear, so devs would have to >>>> remember both. >>> >>> I agree it is a con, but is it a blocker? I mean basically any change >>> proposed requires know the old way, and the new way..that is how >>> changes work... >> >> Which is why changes need to have clear benefits that outweigh the >> costs of change. In this case the benefits are purely cosmetic, so >> they don't. Change for change' sake is not worth the effort. >> >> -- >> Cheers, >> >> Ben | yngwin >> Gentoo developer >> Gentoo Qt project lead, Gentoo Wiki admin >> > > I'm sorry. Are you reading the same threads that I am? You've seen me participating in those, so obviously: yes. > From the other thread ("example conversion of gentoo-x86 current deps > to unified dependencies"): > >> 1) This unifies the existing syntax down into a collapsed form. In >> doing so, there are measurable gains across the board for PM >> efficiency and rsync alone. Unifying existing syntax = cosmetic If collapsing it is beneficial for PM internals, please do so internally while hiding it from ebuild devs. >> 2) In unifying the syntax via reusing our /existing fucking syntax/, >> we formalize the adhoc common dependency assignments devs already are >> doing in the tree. Again, cosmetic >> 3) In moving to a unified syntax, it positions us to easily introduce >> new dependency types without introducing more redundancy. Easier to >> add new dep types, faster to add new dep types, more efficient in >> doing so in comparison to existing approaches, and done in a fashion >> that devs can reuse existing conditionals. Again, cosmetic Note that adding new dep types only comes up very rarely. >> 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based. >> Meaning you do not need to knee-jerk attack it because of some notion >> it's ciaran based/related. Hm, yeah, so? > I know you must have seen this (and the rest...). You've participated > in that thread. Indeed. So what made you wonder if I had seen that? -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin