[gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in app-admin/chrpath: ChangeLog chrpath-0.13-r2.ebuild

[Steven J Long]

Samuli Suominen wrote:

> On 10/12/2011 06:30 AM, Steven J Long wrote:
>> Michał Górny wrote:
>>> I don't think that passing multiple files to epatch actually improves
>>> readability. Simple example:
>>>
>>> # bug #123456, foo, bar
>>> epatch "${FILESDIR}"/${P}-foo.patch
>>> # bug #234567, baz bazinga blah blah
>>> epatch "${FILESDIR}"/${P}-baz.patch
>>>
>>> With multiple arguments, you can't put comments in the middle.
>>>
>> ++ It's also a lot easier to remove the single patches when they're no
>> longer needed.
>
> Removing an 'epatch foo' line is easier than 'foo \' ?  You are kidding,
> right?
>
No; in general, most editors make it really simple to delete a line. Not 
having to worry about line-continuation is just another routine memo that 
doesn't have to be kept in mind*, and I'd argue that it's useful to readers 
of the ebuild, to have the bug # in the ebuild.

* All right, not a *lot* easier, just a bit ;-)

>> In the context of configuring, building and installing a
>> package, the extra overhead is miniscule, whereas the above is *much*
>> easier to maintain.
>
> Based on what argument?
Based on it being easier to edit, and easier to look up the bug straight 
from the ebuild, should someone working with an ebuild choose (or need) to 
do so. I guess I'm arguing for Mike's style within the ebuild (tho that 
PATCHES array looks nice and allows bug # comments.)

Again, perhaps '*much*' went a bit far; sorry for that.

> Having the comments inside the patch allows everyone, including
> _upstreams_ straight up see what's it for and link to the bug it's
> coming from. Where as keeping them in ebuilds makes it Gentoo specific,
> which is not what we are about.
Having a bug # in the ebuild doesn't excuse anyone from having correct 
comments in the patch; they're orthogonal imo. Personally I think you should 
do both; bug # in ebuild* so a user can quickly look up what's happening, 
and both full bug URL, and a fuller explanation in the patch. Bug # in 
ebuild is also useful when you get an ebuild from someone and no patches in 
files/ as it's effectively a fragment. You can argue it's redundant; I see 
it as equivalent to a doubly-linked list: you don't _need_ both links to 
function, but it makes things easier.

In any event you're the maintainer; but this was a discussion about style, 
well "readability" at least, and I think it's better practice to have bug # 
in ebuild.

Regards,
igli.
----
* After all, you only add the bug id once, when you're adding the patch and 
are well aware of what bug/s you're working on; it's not an ongoing burden.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)