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 1434E138010 for ; Mon, 1 Oct 2012 00:07:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A15D921C0A5 for ; Mon, 1 Oct 2012 00:07:56 +0000 (UTC) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by pigeon.gentoo.org (Postfix) with ESMTP id DC09221C00B; Sun, 30 Sep 2012 21:56:19 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id ds1so952040wgb.4 for ; Sun, 30 Sep 2012 14:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=2OdhLu/7bgWaViD+r04kex62ClIRiC+MUw6Bxau1Zic=; b=UKWAT2JwhhDtvEeVW0QxDNzyJi4Nz96UL6il/h+As5/bJ4AmiSqJbAss6gBllDZu66 RDAMvvnFQ0/g38bu5naaXdl7u2Op4kmCow4ZgQL3h+28ksuU5QGgSSvCD0h03K4xxcnL QX9F6Uf9Ta2giOk75m0r5WFJLaBGAd/AKjagZuoS7UdGEXXjuW6RTR6O2cjL+56I1Wsi euGAyW/yoxaas217mm+Dp4DHWNzhePQ9Uv22ZWqwfAj4zi49b4/fIYfoRxKDJXN+wBv/ dg1G0JhxfqGCW8iF662HOa4kKtVznTYi/yf4CCUXrbBhKe/MAHARL5FIhBcORpBHIcsf POxg== Received: by 10.180.94.164 with SMTP id dd4mr10326241wib.1.1349042178949; Sun, 30 Sep 2012 14:56:18 -0700 (PDT) Received: from localhost (cpc13-broo7-2-0-cust130.14-2.cable.virginmedia.com. [82.9.16.131]) by mx.google.com with ESMTPS id v3sm14852025wiy.5.2012.09.30.14.56.17 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Sep 2012 14:56:18 -0700 (PDT) Date: Sun, 30 Sep 2012 22:53:40 +0100 From: Ciaran McCreesh To: Brian Harring Cc: gentoo-pms@lists.gentoo.org, gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal Message-ID: <20120930225340.126b1027@googlemail.com> In-Reply-To: <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> <20120930214214.GE2180@localhost> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.11; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Package Manager Specification discussions X-BeenThere: gentoo-pms@gentoo.org X-BeenThere: gentoo-pms@lists.gentoo.org Reply-To: gentoo-pms@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/=j22cSLr6XataUB4i11gHoH"; protocol="application/pgp-signature" X-Archives-Salt: 4eeeb939-87f0-4ed7-85fe-ad9031d8b49f X-Archives-Hash: fc53372045df3958263750e2a703ed98 --Sig_/=j22cSLr6XataUB4i11gHoH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring wrote: > Reality is, our current form can handle deps generally fine- what you=20 > label as trivial is the vast majority- I argue effectively all. We could do away with half of the current feature set if we were only interested in making things nice for the "vast majority" of cases... > This statement of yours however is fairly disenguous; label behaviour=20 > when nested suffers the same mental parsing oddity (wait, we're in=20 > build context, and this is test? Wtf happens there?). No, label behaviour is local, and scope independent. > Means that 'blah' target doesn't show up. Which is the *same* as > what happens if someone did thus in our existing syntax: >=20 > x? ( !x? ( blah ) ) >=20 > Worth noting, you didn't ban that from exherbo; you left that to sort=20 > itself out, same as I'm doing for dep:blah flags. Were I punching=20 > below the belt, the word 'hypocritical' would likely be involved. That's "not fixing an existing screw-up", which is not the same at all as "adding a new screw-up". > > 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". >=20 > Fairly weak argument at best; you're claiming that via labels,=20 > "contextually they know it's these deps" in comparison to via=20 > dep:build "contextually they know it's exposed only in build". >=20 > Same difference. It's rather a big deal now that we have :=3D dependencies. > > 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. >=20 > I'll buy that argument, and to some degree- agree. >=20 > I just view that as academic wankery without real world gain. >=20 > So like I said, academically possible, but=20 > pragmatically/unrealistically unneded. Labels are almost as easy to implement as your "filtering" model, and they come with the benefit of a better syntax for developers. Even if labels are noticably more work to implement, which I'm not convinced is the case, it's worth paying that price a couple of times in package manglers rather than having developers pay the price of worse syntax in thousands of ebuilds. Filtering is a whole new mechanism anyway. But here's the thing: when you sell something as "pragmatic", what you're really saying is "it's wrong, I know it's wrong, and I'm going to pretend that wrong is a good thing". Getting it wrong should be something you do only after you're sure you can't afford get it right; it shouldn't be something you're proud of. > In my proposal, I am addressing labels; will fold in your claims, but=20 > those claims basically are shit- however, if you *did* find a=20 > conflicting nested example that wasn't contrived, preferablly=20 > multiple, I'd like those examples so I can include them into the=20 > proposal (give labels a fair hand, basically). You already have an example in your proposal, in the form of mplayer's X? ( ) dependencies. But that's missing the point. Even if you pretend complicated dependencies don't exist, labels are still by far the better proposal. Your argument boils down to "it's more pragmatic to do a quick and dirty implementation in Portage and thus force the technical debt onto every single ebuild than it is to do it cleanly". --=20 Ciaran McCreesh --Sig_/=j22cSLr6XataUB4i11gHoH Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBov2cACgkQ96zL6DUtXhHYRQCfT6TqNjHhWol1FoDk3LERT6eD dRAAoJuyqIa0RtSNzPyoYfZyyhFmPCDe =QOhR -----END PGP SIGNATURE----- --Sig_/=j22cSLr6XataUB4i11gHoH--