1 |
On Thu, 3 Aug 2017 19:21:12 +0200 |
2 |
Jonas Stein <jstein@g.o> wrote: |
3 |
|
4 |
> We have already some HOMEPAGES which are constructed by eclass magic |
5 |
> [2]. These do not link to a useful website usually. |
6 |
|
7 |
Statistically, that 99% of perl-module.eclass consumers do just this in |
8 |
a useful way with factoring in ${PN} automatically, might tilt those |
9 |
odds of "Usual" |
10 |
|
11 |
It would be a net reduction in usefulness if every single |
12 |
perl-module.eclass consumer was required to hard-code a human usable |
13 |
HOMEPAGE. |
14 |
|
15 |
In fact, one of the things we have as a future option is changing the |
16 |
"base part" of these automatically generated URL's so they reference a |
17 |
useful homepage on metacpan.org instead of search.cpan.org. |
18 |
|
19 |
I'm glad we're not considering doing that manually for every ebuild. |
20 |
|
21 |
Though, neither of these really are considered "the" home page, but |
22 |
these projects don't typically even *have* "a" homepage, they're |
23 |
simply external-indexes of uploaded data, and they serve as defacto |
24 |
homepages, and metadata inside that uploaded data can direct users to |
25 |
the "real" home page. |
26 |
|
27 |
So in a sense, these home pages also serve like a kind of resolver. |
28 |
|
29 |
But people practically never use that "real" homepage, the defacto home |
30 |
pages are what people care for. |
31 |
|
32 |
> A string is also less error prone. We have already many broken |
33 |
> HOMEPAGES |
34 |
|
35 |
That clearly depends on circumstances, if well tuned, every ebuild hand |
36 |
coding its home pages *increases* the net error prone-ness ( at least, |
37 |
it does for CPAN ), because it creates quite literally thousands of |
38 |
places humans might encode a home page wrong. |
39 |
|
40 |
And at least with CPAN, if the autogenerated homepage does not resolve, |
41 |
that usually doesn't mean you made a mistake in generating the |
42 |
homepage: It usually means you made big bungles somewhere else and the |
43 |
ebuild won't even work, and/or upstream have pulled their rip cord and |
44 |
have deleted all their files from public servers. |
45 |
|
46 |
But this subject kinda reduces to a long-living decision quandry: "to |
47 |
de-duplicate and unify, or not to deduplicate and keep sparse". |
48 |
|
49 |
There are so many benefits and trade-offs to either. It only makes |
50 |
sense to let the decision follow the nature of the problem at hand, not |
51 |
creating a blind rule that must be followed religiously. |