Jan Kundrát <jkt@g.o> writes:

> But also the need to replicate http://www.kde.org/ to metadata.xml of
> all KDE split ebuilds -- right now, this is set by an eclass.

The usefulness of this is IMHO debatable; why not just writing it one
package (say kde-base/kde or kde-meta) and just there? Having each
mini-package express itself as having that as its homepage is not very
useful to me, but I guess it's debatable.

>> - allows proper handling of packages lacking a HOMEPAGE;
>
> Could you elaborate a bit about how different is handling of an
> empty/uninitialized shell variable from an empty XML element?

That you can provide _other_ links beside an homepage, like
"unmaintained", "gentoo:userguide" and stuff like that so that user
don't just get no homepage at all, and they are not misdirected by
homepage being http://www.gentoo.org/ or something.

>> - 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;
>
> Haven't we already agreed that accessing ebuilds/... directly is
> broken by design?

For a software sure, but as an user I am automatically brought to just
look at the files if I'm looking for the homepage of a package I know,
and seeing a metadata.xml file I'm more likely to look at that rather
than the metadata cache in /var/db/... .

And it's certainly more user-readable an XML file than HOMEPAGE with
depend-like syntax for labels and conditionals and whatever else seems
like Alec is proposing for EAPI=3

>> - webapps like packages.gentoo.org would be able to display basic
>>   information without having to parse the ebuilds or the metadata cache.
>
> Except for the ebuilds which still use the old format (that is 100% of
> the tree right now)

This of course is meant as "whenever this is fully implemented"

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/