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 BFCB3138010 for ; Tue, 18 Sep 2012 09:25:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C4B8C21C0BE; Tue, 18 Sep 2012 09:25:11 +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 DEA6721C058; Tue, 18 Sep 2012 09:24:16 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so11797588pbb.40 for ; Tue, 18 Sep 2012 02:24: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=GlsxSPW5a3JIv636n6rA7DYq0WNYXZW3NU/PPv434XA=; b=hVPvJlGxhs8lYbbcc5ToikEysjr76mflUANFXOjO/V34zhrtk6SfUOE2sUsk5tVhva Pd1KwcFqEWSMvDeAh8ZclUT64Hb51agiIKwVGJRrGRlPeLfHcuhlc0IreohyrTpbfRb9 4n7878pdGLdDGkDpqBxdEYZyT7poKwfylxAl04YuobkhUO/uKKItOpOMrowe//+mf8BM hJcmhvct4LmBAR0UfvRQqEoKhUlm8Onv2FZ03j7mFupfQNUgshzX39HoQyBuEVxx85Jb zdGEyKjWluCmXLfzkd6Ez7/3MAIjpfhZu79In0keiXl/f5TUUlxYFbWobtYjb3MSBkbq YChQ== Received: by 10.66.75.229 with SMTP id f5mr25135447paw.47.1347960256120; Tue, 18 Sep 2012 02:24: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 qn3sm8363717pbc.6.2012.09.18.02.24.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 02:24:15 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Tue, 18 Sep 2012 02:24:26 -0700 Date: Tue, 18 Sep 2012 02:24:26 -0700 From: Brian Harring To: Micha?? G??rny Cc: gentoo-dev@lists.gentoo.org, gentoo-pms@lists.gentoo.org Subject: Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal Message-ID: <20120918092426.GA5384@localhost> References: <20120916135211.GC23030@localhost> <20120918102551.500ff19b@pomiocik.lan> 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: <20120918102551.500ff19b@pomiocik.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 7dc2f108-ccb2-4ec0-ab40-05199b57df2c X-Archives-Hash: 872c12c31a1c74965ab7263f7d4432ef On Tue, Sep 18, 2012 at 10:25:51AM +0200, Micha?? G??rny wrote: > > test depends: to specifically mark those dependencies that are only > > needed for when the pkg is being tested; effectively ephemeral > > build/run time depends that go away once testing is completed. > > Does that mean that USE=test is going away somehow? If you think it through, a test use flag still is needed in the cases where the rdep itself would change if test was enabled; such a source is fairy rare, but not always just someone being moronic- certain cases to do testing, the tests need to reach in fairly deeply and recompilation for compile vs test isn't exposed. > Also, could you please stop spreading FUD with your examples? It's not FUD; it's rendered deps, and a demonstration of how they collapse down naturally on their own regardless of how you generate them. Quite frankly, it's a fairly effective demonstration in my views, but so it goes. > A quick > glance shows that what you have expanded there, a fairly reasonable > Gentoo dev will solve using: > > RDEPEND="[common depends]" > DEPEND="${RDEPEND} > [build only depends]" from diffball (under current EAPIs) """ RDEPEND=">=sys-libs/zlib-1.1.4 >=app-arch/bzip2-1.0.2 app-arch/xz-utils" DEPEND="${RDEPEND} virtual/pkgconfig" """ becomes the following under the proposal: """ DEPENDENCIES=">=sys-libs/zlib-1.1.4 >=app-arch/bzip2-1.0.2 app-arch/xz-utils" dep:build? ( virtual/pkgconfig )" """ Suspect I may add that to the doc; it's a good example of the ground level simple gains for devs inherent in the proposal- thanks for helping improve it. > So if you really want to show some advantages, please compare it with > *real* code. I think I'll take the risk, and assume people capable of discussing DEPENDENCIES and vaguely knowledgable in the ebuild format will be able to understand how their ebuilds will change; thus I'll skip that request of yours. A productive suggestion for you; you should go looking through the tree finding cases where DEPENENCIES is a regression in form at the shell level, or rendered deps level. Should you manage to find something that's not contrived or intentionally cracktastic, I expect people would be interested. ~harring