On Mon, 01 Dec 2008 00:12:23 +0100 [EMAIL PROTECTED] (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
signature.asc
Description: PGP signature
