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 ;-)
