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 A40D41381F4 for ; Mon, 13 Aug 2012 12:12:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3C94A21C01D for ; Mon, 13 Aug 2012 12:12:52 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E0D7DE05ED for ; Mon, 13 Aug 2012 10:52:03 +0000 (UTC) Received: from [192.168.0.53] (nsg93-9-78-225-4-220.fbx.proxad.net [78.225.4.220]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eva) by smtp.gentoo.org (Postfix) with ESMTPSA id D0C011B400A for ; Mon, 13 Aug 2012 10:52:02 +0000 (UTC) Message-ID: <1344855117.17434.9.camel@kanae> Subject: Re: [gentoo-dev] SRC_URI in metadata.xml From: Gilles Dartiguelongue To: gentoo-dev@lists.gentoo.org Date: Mon, 13 Aug 2012 12:51:57 +0200 In-Reply-To: <20120810162127.493a455a@marga.jer-c2.orkz.net> References: <5024EC6C.3070300@anche.no> <1344600203.17434.3.camel@kanae> <20120810162127.493a455a@marga.jer-c2.orkz.net> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 8bit 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 X-Archives-Salt: 05f53704-d180-49b5-9c65-7d5897f3e31f X-Archives-Hash: 2ff9aba849373fe5e57f85401630ebc3 Le vendredi 10 août 2012 à 16:21 +0200, Jeroen Roovers a écrit : > 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) I was not suggesting to erase SRC_URI from all ebuilds but for things that have well defined rules like gnome packages, defining SRC_URI is mostly a useless excercise. 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. > I will add against my own question that eclasses currently handle this (see gnome.org eclass) very well. So maybe there is nothing to debate here :)