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.
