While the KDE eclass doesn't set specific homepages per packages, a number of other eclasses do:
eclass/horde.eclass:HOMEPAGE="http://www.horde.org/${HORDE_PN}"; eclass/java-pkg-2.eclass: HOMEPAGE="http://commons.apache.org/${PN#commons-}/"; eclass/kernel-2.eclass:HOMEPAGE="http://www.kernel.org/ http://www.gentoo.org/ ${HOMEPAGE}" eclass/perl-module.eclass: HOMEPAGE="http://search.cpan.org/search?query=${MY_PN:-${PN}}&mode=dist"; eclass/php-ext-pecl-r1.eclass:HOMEPAGE="http://pecl.php.net/${PECL_PKG}"; eclass/php-pear-r1.eclass:[[ -z "${HOMEPAGE}" ]] && HOMEPAGE="http://pear.php.net/${PHP_PEAR_PKG_NAME}"; eclass/ruby.eclass:HOMEPAGE="http://raa.ruby-lang.org/list.rhtml?name=${PN}"; eclass/xfce44.eclass: HOMEPAGE="http://thunar.xfce.org/pwiki/projects/${MY_PN}"; Additionally, some of the above eclasses are used by other eclasses: ant-tasks, java-gnome, perl-app, perl-post, php-ext-pecl, php-ezc, php-pear, gems A quick scan of the tree shows 15% of the ebuilds do not set the HOMEPAGE variable in the ebuild itself. And a LOT more qualify, esp. in dev-ruby and dev-perl. Some quick scanning on groups of packages that I'm aware of puts the figure beyond 20% of the tree qualifying (converting any dev-perl/perl-core package that comes from CPAN). As another major pain, for ebuilds where the homepage changes every version in some predictable pattern, you have now increased the maintenance burden. Before we could just copy the ebuild if we had a suitable variable expression in the HOMEPAGE variable, but now we'd have to edit it into metadata.xml as well. For all the rest of the ebuilds where it does remain static, I don't see any actual advantage to removing it from the ebuilds. To be very clear however, I've got _zero_ objections to adding the extra new fields into the metadata.xml, provided they are version independent. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgp24EsyRaSjN.pgp
Description: PGP signature
