"Alec Warner" <[EMAIL PROTECTED]> writes: > Diego, What are the concrete benefits of your proposal?
As I said: - 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; - allows proper handling of packages lacking a HOMEPAGE; - less data in metadata cache; - 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; - displaying info about the package does not require parsing the full ebuild file, with its eclasses; - extensible to provide more links than just the homepage (forums, trackers, gentoo-specific documentation, ...); - 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; - webapps like packages.gentoo.org would be able to display basic information without having to parse the ebuilds or the metadata cache. - 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; - 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: - 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: - 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. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/
pgpJevDGzJEf0.pgp
Description: PGP signature
