On Mon, 01 Dec 2008 00:12:23 +0100
flameeyes@... (Diego 'Flameeyes' Pettenò) wrote:
> - 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;

You mean "no way of handling generated homepages, use conditional
homepages, per version homepages or common homepages".

> - allows proper handling of packages lacking a HOMEPAGE;

Uh, we can do that using in-ebuild HOMEPAGE too. Just need to decide on
a convention.

> - less data in metadata cache;

Entirely a non-issue. Heck, we want more in there, not less. 

> - 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;

...or they can just use a decent too. Try 'paludis --query' for an
example.

> - displaying info about the package does not require parsing the full
>   ebuild file, with its eclasses;

Uhm. It doesn't anyway, because of the metadata cache.

> - extensible to provide more links than just the homepage (forums,
>   trackers, gentoo-specific documentation, ...);

So's HOMEPAGE. You could extend the syntax to allow annotations:

HOMEPAGE="
    http://example.com/
    http://forums.example.com/ [[ role = forums ]]
    http://www.gentoo.org/example [[ role = [ Gentoo specific docs ] ]]
    gtk+? ( http://gui.example.com/ [[ role = [ Optional GUI docs ] ]]
    "

> - 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;

Except that any decent search client needs to be aware of masks,
visibility and so on anyway.

> - webapps like packages.gentoo.org would be able to display basic
>   information without having to parse the ebuilds or the metadata
> cache.

But they already display complex information.

> - 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;

...or you could use a proper ebuild-aware tool that displays metadata
details, including things like visibility. Again, paludis --query.

> - 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).

It isn't non-functional.

> 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.

"More approachable" is a decent package manager API. If you had that
you wouldn't need to mess around with XML APIs.

-- 
Ciaran McCreesh