From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1ErBtL-00046p-SW for garchives@archives.gentoo.org; Tue, 27 Dec 2005 10:17:16 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBRAGX2o030548; Tue, 27 Dec 2005 10:16:33 GMT Received: from hermes.orakel.ods.org (dsl67-66.fastxdsl.nl [62.251.66.67]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBRAEhSd020329 for ; Tue, 27 Dec 2005 10:14:43 GMT Received: from aphrodite.orakel.ods.org ([172.17.2.15]) by hermes.orakel.ods.org with esmtp (Exim 4.54) id 1ErBqs-0004GN-BX for gentoo-dev@lists.gentoo.org; Tue, 27 Dec 2005 11:14:43 +0100 Received: by aphrodite.orakel.ods.org (Postfix, from userid 501) id 2D31C1BD368; Tue, 27 Dec 2005 11:14:38 +0100 (CET) Date: Tue, 27 Dec 2005 11:14:38 +0100 From: Grobian To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Allow upstream tags in metadata.xml Message-ID: <20051227101438.GI583@gentoo.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <9e83288a0512261611v6861e351tb75367c7a30e264e@mail.gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Disposition: inline In-Reply-To: <9e83288a0512261611v6861e351tb75367c7a30e264e@mail.gmail.com> User-Agent: Mutt/1.5.11 (Darwin 8.3.0, VIM - Vi IMproved 6.2) Organization: Gentoo Foundation, Inc. X-Content-Scanned: by hermes.orakel.ods.org (Exim Exiscan) using SpamAssassin and ClamAV X-Archives-Salt: 44620712-befd-411b-a5b4-7f292811a7b9 X-Archives-Hash: 377779388ee37782173636090ba36214 On 26-12-2005 22:11:46 -0200, Marcelo Ges wrote: > Fellow Gentooers, > > Here is a draft of an enhancement proposal that should allow upstream > information to be included in metadata.xml: > > http://dev.gentoo.org/~vanquirius/glep-0099.txt using http://www.gentoo.org/proj/en/glep/glep-0046.html The bugs-to tag can hold either an email address or URL. Not a big issue, but why not make it an URI, such that an email address is written as "mailto:foo@bar.bar"? Using an URI gives a nice specified format (already including the http(s) which you require) and should go with regular URI parsers. Given the URI thing, maybe it can be useful to define the changelog tag to have an URI as well, since some upstreams ship the changelog with the sources and don't put them on the web. In such case you might want to use a "file://" URI to point to the file on disk when installed? I realise this is tricky. Not clear from the text, but I take it from the example that remote-id has an attribute named "type" which points to some source. Is there a reason to make that an attribute, instead of a tag? Also, the remote-id tag in the example has a TEXT node which apparently is the id, but needs some information in order to track it. Taking your SourceForge example: adium Usually for SourceForge means that "adium" in this case is the "UNIX project name", hence an URL such as http://sourceforge.net/projects/adium points to the project's SourceForge home, while http://adium.sourceforge.net/ points to the project's home page. It's not clear for me where this is different from the home page URL in the ebuild itself. I don't know if FreshMeat can be a real project home. What I wanted to say, where is the logic stored on how to make this id into some resource? And if you store that logic somewhere, why not in the XML structure? Any reason to use an id, and not for instance an URI to the remote 'developers' homepage/resource? Observation: the added data is mainly targetted at developers, not users. Given the ongoing discussion, this might be an interesting side note. In an overlay I'm currently keeping 'portnotes' in metadata.xml, which basically give us developers a quick look on what was necessary to port an ebuild. This is by no means interesting for a regular user, and we put it in metadata.xml because that allows to group the portnotes, since XML is a bit more structured than a changelog. For the sake of rsyncs/speed/storage/whatever, perhaps this purely targetted at developers information should be put in a separate file, which is by default excluded in the rsync? -- gentoo-dev@gentoo.org mailing list