On Thu, Aug 3, 2017 at 11:54 AM, Michał Górny <[email protected]> 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.
