"Alec Warner" <antarus@g.o> 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/