| 1 |
On 08/04/2017 02:50 AM, Michał Górny wrote: |
| 2 |
> |
| 3 |
> Why is it fine for you to handicap everyone else for your personal |
| 4 |
> laziness? As it's been told more than once, you write ebuild *once*, |
| 5 |
> people read it *multiple times*. |
| 6 |
|
| 7 |
Look, I'm sorry if I've been overly confrontational. I emailed angry and |
| 8 |
I know better. There's obviously two opinions on this and I don't want |
| 9 |
to make your life any harder, either. |
| 10 |
|
| 11 |
The write-once read-many discussion comes down to what you think is |
| 12 |
easier to read, which can either mean literally read, or to develop on |
| 13 |
top of. When verifying the URL in a submitted ebuild, I agree that the |
| 14 |
no-variable form is easier to read and has the advantage that you can |
| 15 |
just click the link on github to see if it works. |
| 16 |
|
| 17 |
But on the other hand, in some of my own ebuilds, I find e.g. |
| 18 |
|
| 19 |
HOMEPAGE="https://github.com/${GITHUB_USER}/${PN}" |
| 20 |
|
| 21 |
easier to read than the long expanded string -- it's obviously correct. |
| 22 |
|
| 23 |
And, if I have two otherwise-identical ebuilds for PECL packages (whose |
| 24 |
homepage is set in an eclass), then I would rather not have the HOMEPAGE |
| 25 |
show up in a diff of the two. Having the whole thing abstracted in an |
| 26 |
eclass makes it easier to maintain these packages. |
| 27 |
|
| 28 |
All this is to say that "easy to read" is in the eye of the beholder. |
| 29 |
For ebuilds in the tree, the beholder is usually the maintainer, which |
| 30 |
is why I think the choice should be left up to him. Our ebuilds are bash |
| 31 |
programs, and in source code, "as little duplication as possible" is a |
| 32 |
strong contributor to "easy to read." |
| 33 |
|
| 34 |
|
| 35 |
> When reviewing pull requests, submitted ebuilds etc. I *have to* verify |
| 36 |
> this stuff. I don't have time to copy everything to a local tree just to |
| 37 |
> get some random tool process it correctly and give me the value I need. |
| 38 |
> Just to figure out there's some trivial issue that blocks any further |
| 39 |
> progress, and I will have to do this again, and again, and again. |
| 40 |
> Because someone thinks it's cool to save 5 bytes in variable references |
| 41 |
|
| 42 |
On 08/04/2017 02:51 AM, Ulrich Mueller wrote: |
| 43 |
> All very well, but it requires the ebuild to a) be parseable by the |
| 44 |
> package manager and b) already exist inside of an ebuild repository. |
| 45 |
> Which is for example not the case for a user contributed ebuild |
| 46 |
> attached to bugzilla. |
| 47 |
|
| 48 |
|
| 49 |
The two use cases cited above apply only to ebuilds outside of the tree, |
| 50 |
but the proposed rule applies only to ebuilds inside of the tree. |
| 51 |
|
| 52 |
Ultimately, you do need to add the ebuild to your local tree. If the |
| 53 |
package manager can't even source it, you have bigger problems than the |
| 54 |
HOMEPAGE. And even if everyone kept variables out of HOMEPAGE, you would |
| 55 |
still need to verify things like SRC_URI with the help of the package |
| 56 |
manager. |
| 57 |
|
| 58 |
Your workflow is whatever it is and I'm not going to tell you it's wrong |
| 59 |
or go out of my way to make it harder, and all I want is the same |
| 60 |
consideration. You're never going to read my ebuilds, but I have to work |
| 61 |
with them every day. And if you wanted to instate a rule for user |
| 62 |
submissions, I wouldn't have a problem with that. |
Archives