From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1L6vT3-0001LN-KS for garchives@archives.gentoo.org; Sun, 30 Nov 2008 23:12:45 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 18BC6E072E; Sun, 30 Nov 2008 23:12:44 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C5046E072E for ; Sun, 30 Nov 2008 23:12:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 497C9643AC for ; Sun, 30 Nov 2008 23:12:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 required=5.5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Dz-piK7soVN for ; Sun, 30 Nov 2008 23:12:36 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id D92546414B for ; Sun, 30 Nov 2008 23:12:35 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L6vSq-0004N2-B0 for gentoo-dev@gentoo.org; Sun, 30 Nov 2008 23:12:32 +0000 Received: from ppp-122-238.21-151.libero.it ([151.21.238.122]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 30 Nov 2008 23:12:32 +0000 Received: from flameeyes by ppp-122-238.21-151.libero.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 30 Nov 2008 23:12:32 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: flameeyes@gmail.com (Diego 'Flameeyes' =?utf-8?Q?Petten=C3=B2?=) Subject: [gentoo-dev] Re: [RFC] Moving HOMEPAGE out of ebuilds for the future Date: Mon, 01 Dec 2008 00:12:23 +0100 Message-ID: References: <49329690.7000409@gentoo.org> <1228053002.5981.12.camel@homer.ob.libexec.de> <1228057415.25651.105.camel@localhost> <4932AC9D.2000401@gentoo.org> <1228064022.25651.151.camel@localhost> 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: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ppp-122-238.21-151.libero.it User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:Fquk7+xiZ0/7Us63bRC1uT/kJ1I= Sender: news X-Archives-Salt: 47d7b84a-f4ac-4d45-a1e7-c5a621ec0c79 X-Archives-Hash: f0390f362045e902b81f5c36d848f852 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "Alec Warner" writes: > Diego, What are the concrete benefits of your proposal? As I said: =2D no need to replicate homepage data between versions; even though forks can change homepage, I would expect that to at worse split in two a package, or have to be different by slot, like Java; =2D allows proper handling of packages lacking a HOMEPAGE; =2D less data in metadata cache; =2D users can check the metadata much more easily by just opening the xml file or interfacing to that rather than having to skim through the ebuild, the xml files are probably more user readable then ebuilds using multiple eclasses; =2D displaying info about the package does not require parsing the full ebuild file, with its eclasses; =2D extensible to provide more links than just the homepage (forums, trackers, gentoo-specific documentation, ...); =2D if we also move DESCRIPTION, search software can ignore everything about ebuild parsing, and just use the metadata.xml files; considering how many people actually use or used eix, it would make sense to allow third-party applications to be able to search through the tree; =2D webapps like packages.gentoo.org would be able to display basic information without having to parse the ebuilds or the metadata cache. =2D as much as people might think metadata is easier to parse than anything, XML has one huge advantage: there are plently of parsers for any language without having to actually write one, even as easy as it can be, and it's easily interfaced with anything; I wrote a simple XSL file that outputs the basic metadata details for packages without having any parser or executable code but xsltproc (or any other XSLT software), correlating data with herds.xml too; =2D it really is metadata, and it makes very little sense to need parsing of eclasses and EAPI handling to get some data from a package that is non-functional in nature and free form (just like DESCRIPTION, and unlike LICENSE like Alec said), and that changes at worse once each slot (unlike LICENSE that can change at any given version). Disadvantages: =2D it requires user-interface software to parse metadata.xml to show data for a package; which is already needed to show per-package USE flag meaning; General points: =2D it does not solve unrelated problems like code replication; Can someone come up with any other point beside "I don't like XML" (which I already said is a puny answer) and "it can theorically be 10 different homepages for 10 different versions" (which I have sincerely some beef with myself since if you fork a software you might as well change its name)? As I said, moving out the HOMEPAGE field from a package manager prospective is non functional; if you're showing to the user some data about a package you might as well show as much as you can, like long descriptions, other links, and USE flags. And the fact that you can ask the package manager for something is for me not a valid reason to avoi moving something in a more approchable place for other software. =2D-=20 Diego "Flameeyes" Petten=C3=B2 http://blog.flameeyes.eu/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkzHdcACgkQe2h1+2mHVWPYqwCgkaMViqguCKyNtHET0Hv+sZ4Z uoIAoIHirfPJ2xqtSmqvt3YTs7LMfKUJ =1PDk -----END PGP SIGNATURE----- --=-=-=--