[gentoo-dev] Allow variable refs in HOMEPAGE

[gentoo-dev] Allow variable refs in HOMEPAGE

[Mike Gilbert]

I would like to remove the ban on variable references in the HOMEPAGE
variable in ebuilds.

As I understand it, this ban was put in place so that people can
easily copy/paste from an ebuild to a web browser.

If people want to copy/paste the URL, they can easily query the final
value using the portage API, or a tool written against it.

% equery m www-client/chromium
 * www-client/chromium [gentoo]
Maintainer:  chromium@gentoo.org (Chromium in Gentoo Project)
Upstream:    None specified
Homepage:    http://chromium.org/
Location:    /home/floppym/repos/gentoo/www-client/chromium
Keywords:    59.0.3071.104:0: x86
Keywords:    60.0.3112.40:0:
Keywords:    60.0.3112.78:0: amd64
Keywords:    61.0.3159.5:0:
Keywords:    61.0.3163.13:0: ~amd64 ~arm ~arm64 ~x86
License:     BSD

Allowing variables in HOMEPAGE would allow for easier copying of
similar/identical ebuilds. For example, see the trivial ebuilds in my
overlay below.

https://bitbucket.org/floppym/floppym-overlay/src/8b55fab291ec1f9be93ade9c91e7d62d7b8a259d/dev-go/cloudflare-go/cloudflare-go-0.7.4.ebuild

https://bitbucket.org/floppym/floppym-overlay/src/8b55fab291ec1f9be93ade9c91e7d62d7b8a259d/dev-go/pkg-errors/pkg-errors-0.8.0.ebuild

https://bitbucket.org/floppym/floppym-overlay/src/8b55fab291ec1f9be93ade9c91e7d62d7b8a259d/dev-go/urfave-cli/urfave-cli-1.19.1.ebuild

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

[Michał Górny]

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

On czw, 2017-08-03 at 11:33 -0400, Mike Gilbert wrote:
> I would like to remove the ban on variable references in the HOMEPAGE
> variable in ebuilds.
> 
> As I understand it, this ban was put in place so that people can
> easily copy/paste from an ebuild to a web browser.
> 
> If people want to copy/paste the URL, they can easily query the final
> value using the portage API, or a tool written against it.

I object! Portage API does not work conveniently for ebuilds scattered
all over the place, or visible through gitweb.

In fact, I would like to request an opposite motion: I would like to ban
all constant-value variable references unless they give a *very* large
measurable benefit.

I'm really tired of people who try hard to replace everything with
a variable when it doesn't give any benefit. It only means that:

- when reviewing multiple ebuilds, I constantly need to look at PN to
figure out whether someone didn't screw up the vars,

- things are not suitable for straightforward copy-paste for testing,

- everything falls apart when someone renames the package (either us or
upstream). In particular, it becomes PITA to figure out which ${PN}
represent the upstream name, and which ones strictly refer to the
package name.

In other words:

a. P/PV/PF are acceptable because versions change frequently,

b. PN might be acceptable when used for MY_P and so on,

c. no variables in HOMEPAGE, EGIT_REPO_URI, constant part of SRC_URI
(so I could at least open the directory containing the file),

d. no random ${PN} all over the install phase.

> Allowing variables in HOMEPAGE would allow for easier copying of
> similar/identical ebuilds. For example, see the trivial ebuilds in my
> overlay below.
> 
> https://bitbucket.org/floppym/floppym-overlay/src/8b55fab291ec1f9be93ade9c91e7d62d7b8a259d/dev-go/cloudflare-go/cloudflare-go-0.7.4.ebuild
> 
> https://bitbucket.org/floppym/floppym-overlay/src/8b55fab291ec1f9be93ade9c91e7d62d7b8a259d/dev-go/pkg-errors/pkg-errors-0.8.0.ebuild
> 
> https://bitbucket.org/floppym/floppym-overlay/src/8b55fab291ec1f9be93ade9c91e7d62d7b8a259d/dev-go/urfave-cli/urfave-cli-1.19.1.ebuild

Laziness shouldn't be an excuse to make things worse. You can write
yourself a tool that puts correct values there.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 988 bytes --]

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

[Jonas Stein]

[-- Attachment #1.1: Type: text/plain, Size: 1064 bytes --]

Hi Mike,

> I would like to remove the ban on variable references in the HOMEPAGE
> variable in ebuilds.
> 
> As I understand it, this ban was put in place so that people can
> easily copy/paste from an ebuild to a web browser.

It made it also possible to grep through the packages and find thousand
dead HOMEPAGES like [1] and many more.

If the HOMEPAGE is constructed by the power of bash variables it is hard
to track and to use.

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

A string is also less error prone. We have already many broken
HOMEPAGES. This number would only increase if we add variables. On the
other hand it does not safe very much time for the maintainer.
Ebuilds are written once, but read many times.

Hence I suggest KISS (keep it simple stupid) and stick to the real URL
without variables.

[1] https://wiki.gentoo.org/wiki/Upstream_repository_shutdowns
[2] https://bugs.gentoo.org/show_bug.cgi?id=624498

-- 
Best,
Jonas





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

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

[Michael Orlitzky]

On 08/03/2017 11:33 AM, Mike Gilbert wrote:
> I would like to remove the ban on variable references in the HOMEPAGE
> variable in ebuilds.
> 

What ban are you referring to? The Portage Manager Specification doesn't
say anything of the sort.

Seriously though, whatever sort of tricks your opponents think they're
doing with HOMEPAGE don't work. The HOMEPAGE can contain conditionals
(i.e. dependency syntax), so grepping and copy/pasting are unreliable,
and we should all continue doing whatever the heck we want.

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

[Michał Górny]

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

On czw, 2017-08-03 at 14:21 -0400, Michael Orlitzky wrote:
> On 08/03/2017 11:33 AM, Mike Gilbert wrote:
> > I would like to remove the ban on variable references in the HOMEPAGE
> > variable in ebuilds.
> > 
> 
> What ban are you referring to? The Portage Manager Specification doesn't
> say anything of the sort.
> 
> Seriously though, whatever sort of tricks your opponents think they're
> doing with HOMEPAGE don't work. The HOMEPAGE can contain conditionals
> (i.e. dependency syntax), so grepping and copy/pasting are unreliable,
> and we should all continue doing whatever the heck we want.

This argument makes no sense. The dependency syntax requires a lot of
spaces which means clicking, copy-pasting and all other fancy stuff just
works™.

It's always nice when someone who doesn't do X tells those actually
doing X that their method doesn't work without any research to support
it.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 988 bytes --]

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

[Mike Gilbert]

On Thu, Aug 3, 2017 at 2:21 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 08/03/2017 11:33 AM, Mike Gilbert wrote:
>> I would like to remove the ban on variable references in the HOMEPAGE
>> variable in ebuilds.
>>
>
> What ban are you referring to? The Portage Manager Specification doesn't
> say anything of the sort.

It's in the devmanual, which imposes gentoo-specific policy on top of PMS.

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

[Michael Orlitzky]

On 08/03/2017 02:57 PM, Mike Gilbert wrote:
> 
> It's in the devmanual, which imposes gentoo-specific policy on top of PMS.
> 

It would be nice if that were true, but there's a lot of junk and/or
personal preference documented in the devmanual, and a lot of
actual-policy that's still missing because it can't get past review.
This looks like it was tacked on for fun as part of the devrel handbook
merger:

https://github.com/gentoo/devmanual.gentoo.org/commit/c97aec7f7e236bc917067763916530bfa05d6e31

(The old handbook never mentioned variables, from what I can see.)

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

[Ulrich Mueller]

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

>>>>> On Thu, 3 Aug 2017, Mike Gilbert wrote:

> I would like to remove the ban on variable references in the
> HOMEPAGE variable in ebuilds.

I think this is not a good idea. For example, it would break
browse-url-at-point (C-u u .) from within Emacs.

> [...]

> Allowing variables in HOMEPAGE would allow for easier copying of
> similar/identical ebuilds. For example, see the trivial ebuilds in
> my overlay below.

Ebuilds are read more often than they are written. IMHO there is no
benefit in optimising the latter at the expense of the former.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Ulrich Mueller]

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

>>>>> On Thu, 3 Aug 2017, Michael Orlitzky wrote:

> [...] Portage Manager Specification [...]

D'oh!

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Mike Gilbert]

On Thu, Aug 3, 2017 at 3:12 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 08/03/2017 02:57 PM, Mike Gilbert wrote:
>>
>> It's in the devmanual, which imposes gentoo-specific policy on top of PMS.
>>
>
> It would be nice if that were true, but there's a lot of junk and/or
> personal preference documented in the devmanual, and a lot of
> actual-policy that's still missing because it can't get past review.
> This looks like it was tacked on for fun as part of the devrel handbook
> merger:
>
> https://github.com/gentoo/devmanual.gentoo.org/commit/c97aec7f7e236bc917067763916530bfa05d6e31
>
> (The old handbook never mentioned variables, from what I can see.)
>

The developer handbook was also a "policy" manual of sorts when it existed.

I don't know where you got the idea that developers are free to ignore
the devmanual when it suits them. You might get away with it if QA
doesn't notice I guess.

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

[Michael Orlitzky]

On 08/03/2017 03:39 PM, Mike Gilbert wrote:
>>
>> (The old handbook never mentioned variables, from what I can see.)
>>
> 
> The developer handbook was also a "policy" manual of sorts when it existed.

The developer handbook that I just said didn't mention variables in
HOMEPAGE at all.

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

[Mike Gilbert]

On Thu, Aug 3, 2017 at 3:56 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 08/03/2017 03:39 PM, Mike Gilbert wrote:
>>>
>>> (The old handbook never mentioned variables, from what I can see.)
>>>
>>
>> The developer handbook was also a "policy" manual of sorts when it existed.
>
> The developer handbook that I just said didn't mention variables in
> HOMEPAGE at all.
>

I really doubt that, but I'm not going to spend time trying to track it down.

Anyway, it's been in the devmanual for 10 years at this point. I don't
feel comfortable just removing it without some kind of developer
consensus or support from QA/council.

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

[Mike Gilbert]

On Thu, Aug 3, 2017 at 11:54 AM, Michał Górny <mgorny@gentoo.org> wrote:
> On czw, 2017-08-03 at 11:33 -0400, Mike Gilbert wrote:
>> I would like to remove the ban on variable references in the HOMEPAGE
>> variable in ebuilds.
>>
>> As I understand it, this ban was put in place so that people can
>> easily copy/paste from an ebuild to a web browser.
>>
>> If people want to copy/paste the URL, they can easily query the final
>> value using the portage API, or a tool written against it.
>
> I object! Portage API does not work conveniently for ebuilds scattered
> all over the place, or visible through gitweb.
>
> In fact, I would like to request an opposite motion: I would like to ban
> all constant-value variable references unless they give a *very* large
> measurable benefit.
>
> I'm really tired of people who try hard to replace everything with
> a variable when it doesn't give any benefit. It only means that:
>
> - when reviewing multiple ebuilds, I constantly need to look at PN to
> figure out whether someone didn't screw up the vars,
>
> - things are not suitable for straightforward copy-paste for testing,
>
> - everything falls apart when someone renames the package (either us or
> upstream). In particular, it becomes PITA to figure out which ${PN}
> represent the upstream name, and which ones strictly refer to the
> package name.
>
> In other words:
>
> a. P/PV/PF are acceptable because versions change frequently,
>
> b. PN might be acceptable when used for MY_P and so on,
>
> c. no variables in HOMEPAGE, EGIT_REPO_URI, constant part of SRC_URI
> (so I could at least open the directory containing the file),
>
> d. no random ${PN} all over the install phase.

After thinking about it, I suppose this makes sense. If we can get
some agreement to use ${PN} and other static values as little as
possible, I can support that.

What really doesn't make sense to me is to ban it just for HOMEPAGE,
but allow it everywhere else.

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

[Ulrich Mueller]

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

>>>>> On Thu, 3 Aug 2017, Michael Orlitzky wrote:

> On 08/03/2017 03:39 PM, Mike Gilbert wrote:
>> The developer handbook was also a "policy" manual of sorts when it
>> existed.

> The developer handbook that I just said didn't mention variables in
> HOMEPAGE at all.

It did, even back in 2004:
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?hideattic=0&revision=1.10&view=markup#l534

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Sam Jorna]

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

On Thu, Aug 03, 2017 at 05:54:17PM +0200, Michał Górny wrote:
> d. no random ${PN} all over the install phase.

I think some qualification of "random ${PN} all over the install phase"
needs to be made - how random is random, are there any allowed
instances?

AFAIK with the exception of some system-wide resources (eg. themes,
icons, fonts) packages installing to locations such as /usr/share and
/usr/share/doc should install to directories named after the package (as
in after ${PN} or ${PF}). This means, when writing src_install(), that
use of those variables would be necessary. Should we always use ${PF}
instead, or are some instances of ${PN} reasonable?

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

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

[Michael Orlitzky]

On 08/03/2017 06:33 PM, Ulrich Mueller wrote:
>>>>>> On Thu, 3 Aug 2017, Michael Orlitzky wrote:
> 
>> The developer handbook that I just said didn't mention variables in
>> HOMEPAGE at all.
> 
> It did, even back in 2004:
> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?hideattic=0&revision=1.10&view=markup#l534
> 

You got me, but now we can see where that text came from and it proves
my original point that the last line was added as an afterthought and
isn't any sort of policy:

  https://bugs.gentoo.org/show_bug.cgi?id=73272

Which is good, because it's a silly rule, and hundreds of ebuilds in the
tree wisely ignore it.

Why single out HOMEPAGE? I might like to copy/paste the econf arguments,
so should we forbid the use of $(use_enable foo) and force everyone to
use "if" statements? Of course not; if you need the value of HOMEPAGE
(or anything else), there are more intelligent ways to get it than
opening up the ebuild, digging though the source code, and manually
performing the variable substitutions that the programming language is
there to do for us.

Use the metadata, use eix, use emerge --search, write an echo statement
into the ebuild, whatever. Don't handicap everyone so that you can treat
their source code as part of your user interface.

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

[Michał Górny]

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

On czw, 2017-08-03 at 23:24 -0400, Michael Orlitzky wrote:
> On 08/03/2017 06:33 PM, Ulrich Mueller wrote:
> > > > > > > On Thu, 3 Aug 2017, Michael Orlitzky wrote:
> > > The developer handbook that I just said didn't mention variables in
> > > HOMEPAGE at all.
> > 
> > It did, even back in 2004:
> > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?hideattic=0&revision=1.10&view=markup#l534
> > 
> 
> You got me, but now we can see where that text came from and it proves
> my original point that the last line was added as an afterthought and
> isn't any sort of policy:
> 
>   https://bugs.gentoo.org/show_bug.cgi?id=73272
> 
> Which is good, because it's a silly rule, and hundreds of ebuilds in the
> tree wisely ignore it.

There's a significant difference between being unaware of a policy
and intentionally disrespecting it. Now that you've been made aware, we
can start pursuing it.

> Why single out HOMEPAGE? I might like to copy/paste the econf arguments,
> so should we forbid the use of $(use_enable foo) and force everyone to
> use "if" statements? Of course not; if you need the value of HOMEPAGE
> (or anything else), there are more intelligent ways to get it than
> opening up the ebuild, digging though the source code, and manually
> performing the variable substitutions that the programming language is
> there to do for us.
> 
> Use the metadata, use eix, use emerge --search, write an echo statement
> into the ebuild, whatever. Don't handicap everyone so that you can treat
> their source code as part of your user interface.

Why is it fine for you to handicap everyone else for your personal
laziness? As it's been told more than once, you write ebuild *once*,
people read it *multiple times*.

When reviewing pull requests, submitted ebuilds etc. I *have to* verify
this stuff. I don't have time to copy everything to a local tree just to
get some random tool process it correctly and give me the value I need.
Just to figure out there's some trivial issue that blocks any further
progress, and I will have to do this again, and again, and again.
Because someone thinks it's cool to save 5 bytes in variable references.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 988 bytes --]

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

[Ulrich Mueller]

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

>>>>> On Thu, 3 Aug 2017, Michael Orlitzky wrote:

> On 08/03/2017 06:33 PM, Ulrich Mueller wrote:
>> It did, even back in 2004:
>> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?hideattic=0&revision=1.10&view=markup#l534

> You got me, but now we can see where that text came from and it
> proves my original point that the last line was added as an
> afterthought and isn't any sort of policy:

>   https://bugs.gentoo.org/show_bug.cgi?id=73272

Huh? We don't know if these changes result from a previous discussion,
or codify best practice at the time. Given that the comment says
"consolidate [...] into the Ebuild HOWTO" I would assume that they
don't appear out of the blue there.

Besides, something that sits in the handbook and devmanual uncontested
since more than a decade certainly is a policy.

> Which is good, because it's a silly rule, and hundreds of ebuilds in
> the tree wisely ignore it.

> Why single out HOMEPAGE? I might like to copy/paste the econf
> arguments, so should we forbid the use of $(use_enable foo) and
> force everyone to use "if" statements? Of course not; if you need
> the value of HOMEPAGE (or anything else), there are more intelligent
> ways to get it than opening up the ebuild, digging though the source
> code, and manually performing the variable substitutions that the
> programming language is there to do for us.

> Use the metadata, use eix, use emerge --search, write an echo
> statement into the ebuild, whatever. Don't handicap everyone so that
> you can treat their source code as part of your user interface.

All very well, but it requires the ebuild to a) be parseable by the
package manager and b) already exist inside of an ebuild repository.
Which is for example not the case for a user contributed ebuild
attached to bugzilla.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Michael Orlitzky]

On 08/04/2017 02:50 AM, Michał Górny wrote:
> 
> Why is it fine for you to handicap everyone else for your personal
> laziness? As it's been told more than once, you write ebuild *once*,
> people read it *multiple times*.

Look, I'm sorry if I've been overly confrontational. I emailed angry and
I know better. There's obviously two opinions on this and I don't want
to make your life any harder, either.

The write-once read-many discussion comes down to what you think is
easier to read, which can either mean literally read, or to develop on
top of. When verifying the URL in a submitted ebuild, I agree that the
no-variable form is easier to read and has the advantage that you can
just click the link on github to see if it works.

But on the other hand, in some of my own ebuilds, I find e.g.

  HOMEPAGE="https://github.com/${GITHUB_USER}/${PN}"

easier to read than the long expanded string -- it's obviously correct.

And, if I have two otherwise-identical ebuilds for PECL packages (whose
homepage is set in an eclass), then I would rather not have the HOMEPAGE
show up in a diff of the two. Having the whole thing abstracted in an
eclass makes it easier to maintain these packages.

All this is to say that "easy to read" is in the eye of the beholder.
For ebuilds in the tree, the beholder is usually the maintainer, which
is why I think the choice should be left up to him. Our ebuilds are bash
programs, and in source code, "as little duplication as possible" is a
strong contributor to "easy to read."


> When reviewing pull requests, submitted ebuilds etc. I *have to* verify
> this stuff. I don't have time to copy everything to a local tree just to
> get some random tool process it correctly and give me the value I need.
> Just to figure out there's some trivial issue that blocks any further
> progress, and I will have to do this again, and again, and again.
> Because someone thinks it's cool to save 5 bytes in variable references

On 08/04/2017 02:51 AM, Ulrich Mueller wrote:
> All very well, but it requires the ebuild to a) be parseable by the
> package manager and b) already exist inside of an ebuild repository.
> Which is for example not the case for a user contributed ebuild
> attached to bugzilla.


The two use cases cited above apply only to ebuilds outside of the tree,
but the proposed rule applies only to ebuilds inside of the tree.

Ultimately, you do need to add the ebuild to your local tree. If the
package manager can't even source it, you have bigger problems than the
HOMEPAGE. And even if everyone kept variables out of HOMEPAGE, you would
still need to verify things like SRC_URI with the help of the package
manager.

Your workflow is whatever it is and I'm not going to tell you it's wrong
or go out of my way to make it harder, and all I want is the same
consideration. You're never going to read my ebuilds, but I have to work
with them every day. And if you wanted to instate a rule for user
submissions, I wouldn't have a problem with that.

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

[Peter Stuge]

Michael Orlitzky wrote:
> All this is to say that "easy to read" is in the eye of the beholder.
> For ebuilds in the tree, the beholder is usually the maintainer, which
> is why I think the choice should be left up to him.

I think what mgorny says is that locality of ebuilds is an important factor.


> Our ebuilds are bash programs, and in source code, "as little
> duplication as possible" is a strong contributor to "easy to read."

Here's an idea: Could a little bit of automated (but obviously checked!)
de-duplication be made [an optional] part of adding an ebuild into the
tree, and please everyone?


//Peter

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

[Kent Fredric]

[-- 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 --]