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 9900913800E for ; Fri, 10 Aug 2012 20:07:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8B0A3E067D; Fri, 10 Aug 2012 20:07:05 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 5772DE05DB for ; Fri, 10 Aug 2012 20:05:21 +0000 (UTC) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: iksaif) by smtp.gentoo.org (Postfix) with ESMTPSA id BC3E91B406E for ; Fri, 10 Aug 2012 20:05:20 +0000 (UTC) Received: by qafi31 with SMTP id i31so389753qaf.19 for ; Fri, 10 Aug 2012 13:05:18 -0700 (PDT) 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.224.179.7 with SMTP id bo7mr9820458qab.15.1344629118897; Fri, 10 Aug 2012 13:05:18 -0700 (PDT) Received: by 10.49.27.35 with HTTP; Fri, 10 Aug 2012 13:05:18 -0700 (PDT) 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> Date: Fri, 10 Aug 2012 22:05:18 +0200 Message-ID: Subject: Re: [gentoo-dev] SRC_URI in metadata.xml From: Corentin Chary To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: e986eb24-01b0-4669-b40e-99af481d16ac X-Archives-Hash: 5e6bf3fe3f22e9307fc25fd4d8f6bed1 On Fri, Aug 10, 2012 at 4:21 PM, Jeroen Roovers wrote: > 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. Right, our proposal is not here to replace SRC_URI, it's here to fix the cases where SRC_URI can't be sanely used to guess new upstream versions (strange mangling rules, unbrowsable directories, etc...). -- Corentin Chary http://xf.iksaif.net