Re: [gentoo-dev] Allow variable refs in HOMEPAGE

[Kent Fredric <kentnl@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2284 bytes --]

On Thu, 3 Aug 2017 19:21:12 +0200
Jonas Stein <jstein@gentoo.org> wrote:

> We have already some HOMEPAGES which are constructed by eclass magic
> [2]. These do not link to a useful website usually.

Statistically, that 99% of perl-module.eclass consumers do just this in
a useful way with factoring in ${PN} automatically, might tilt those
odds of "Usual"

It would be a net reduction in usefulness if every single
perl-module.eclass consumer was required to hard-code a human usable
HOMEPAGE.

In fact, one of the things we have as a future option is changing the
"base part" of these automatically generated URL's so they reference a
useful homepage on metacpan.org instead of search.cpan.org.

I'm glad we're not considering doing that manually for every ebuild.

Though, neither of these really are considered "the" home page, but
these projects don't typically even *have* "a" homepage,  they're
simply external-indexes of uploaded data, and they serve as defacto
homepages, and metadata inside that uploaded data can direct users to
the "real" home page.

So in a sense, these home pages also serve like a kind of resolver.

But people practically never use that "real" homepage, the defacto home
pages are what people care for.

> A string is also less error prone. We have already many broken
> HOMEPAGES

That clearly depends on circumstances, if well tuned, every ebuild hand
coding its home pages *increases* the net error prone-ness ( at least,
it does for CPAN ), because it creates quite literally thousands of
places humans might encode a home page wrong.

And at least with CPAN, if the autogenerated homepage does not resolve,
that usually doesn't mean you made a mistake in generating the
homepage:  It usually means you made big bungles somewhere else and the
ebuild won't even work, and/or upstream have pulled their rip cord and
have deleted all their files from public servers.

But this subject kinda reduces to a long-living decision quandry: "to
de-duplicate and unify, or not to deduplicate and keep sparse".

There are so many benefits and trade-offs to either. It only makes
sense to let the decision follow the nature of the problem at hand, not
creating a blind rule that must be followed religiously.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]