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 83FC813800E for ; Fri, 10 Aug 2012 14:22:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C24E2E06F7; Fri, 10 Aug 2012 14:22:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 36AD8E06C0 for ; Fri, 10 Aug 2012 14:21:33 +0000 (UTC) Received: from marga.jer-c2.orkz.net (D4B2706A.static.ziggozakelijk.nl [212.178.112.106]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jer) by smtp.gentoo.org (Postfix) with ESMTPSA id 19F591B4098 for ; Fri, 10 Aug 2012 14:21:31 +0000 (UTC) Date: Fri, 10 Aug 2012 16:21:27 +0200 From: Jeroen Roovers To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] SRC_URI in metadata.xml Message-ID: <20120810162127.493a455a@marga.jer-c2.orkz.net> In-Reply-To: <1344600203.17434.3.camel@kanae> References: <5024EC6C.3070300@anche.no> <1344600203.17434.3.camel@kanae> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; i686-pc-linux-gnu) 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-Transfer-Encoding: 7bit X-Archives-Salt: 5d3c49c5-803d-4436-a5e2-af17dbc0412a X-Archives-Hash: fe5806555dfd02c895865fb48e3da0b6 On Fri, 10 Aug 2012 14:03:23 +0200 Gilles Dartiguelongue wrote: > Since you are proposing this, a side question is: > Why should we write SRC_URI in ebuilds if that info is now available > in metadata.xml ? (granted that we might still want to keep > over-riding this information in ebuilds) 1) The information in metadata.xml is inaccurate, it's a hint. When it fails, nothing of value is lost since the ebuild (supposedly) has what you want. 2) SRC_URI is precise. 3) SRC_URI can change over time, and across versions (even with all the variables in place). 4) Backward compatibility. 5) The inversion of your question: Why should we start handling SRC_URI outside ebuilds and eclasses? Or, how would that be practical, advantageous, an improvement on the current situation. jer