Jan Kundrát <[EMAIL PROTECTED]> 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/
pgpfOxlYEmqMh.pgp
Description: PGP signature
