1 |
Samuli Suominen wrote: |
2 |
|
3 |
> On 10/12/2011 06:30 AM, Steven J Long wrote: |
4 |
>> Michał Górny wrote: |
5 |
>>> I don't think that passing multiple files to epatch actually improves |
6 |
>>> readability. Simple example: |
7 |
>>> |
8 |
>>> # bug #123456, foo, bar |
9 |
>>> epatch "${FILESDIR}"/${P}-foo.patch |
10 |
>>> # bug #234567, baz bazinga blah blah |
11 |
>>> epatch "${FILESDIR}"/${P}-baz.patch |
12 |
>>> |
13 |
>>> With multiple arguments, you can't put comments in the middle. |
14 |
>>> |
15 |
>> ++ It's also a lot easier to remove the single patches when they're no |
16 |
>> longer needed. |
17 |
> |
18 |
> Removing an 'epatch foo' line is easier than 'foo \' ? You are kidding, |
19 |
> right? |
20 |
> |
21 |
No; in general, most editors make it really simple to delete a line. Not |
22 |
having to worry about line-continuation is just another routine memo that |
23 |
doesn't have to be kept in mind*, and I'd argue that it's useful to readers |
24 |
of the ebuild, to have the bug # in the ebuild. |
25 |
|
26 |
* All right, not a *lot* easier, just a bit ;-) |
27 |
|
28 |
>> In the context of configuring, building and installing a |
29 |
>> package, the extra overhead is miniscule, whereas the above is *much* |
30 |
>> easier to maintain. |
31 |
> |
32 |
> Based on what argument? |
33 |
Based on it being easier to edit, and easier to look up the bug straight |
34 |
from the ebuild, should someone working with an ebuild choose (or need) to |
35 |
do so. I guess I'm arguing for Mike's style within the ebuild (tho that |
36 |
PATCHES array looks nice and allows bug # comments.) |
37 |
|
38 |
Again, perhaps '*much*' went a bit far; sorry for that. |
39 |
|
40 |
> Having the comments inside the patch allows everyone, including |
41 |
> _upstreams_ straight up see what's it for and link to the bug it's |
42 |
> coming from. Where as keeping them in ebuilds makes it Gentoo specific, |
43 |
> which is not what we are about. |
44 |
Having a bug # in the ebuild doesn't excuse anyone from having correct |
45 |
comments in the patch; they're orthogonal imo. Personally I think you should |
46 |
do both; bug # in ebuild* so a user can quickly look up what's happening, |
47 |
and both full bug URL, and a fuller explanation in the patch. Bug # in |
48 |
ebuild is also useful when you get an ebuild from someone and no patches in |
49 |
files/ as it's effectively a fragment. You can argue it's redundant; I see |
50 |
it as equivalent to a doubly-linked list: you don't _need_ both links to |
51 |
function, but it makes things easier. |
52 |
|
53 |
In any event you're the maintainer; but this was a discussion about style, |
54 |
well "readability" at least, and I think it's better practice to have bug # |
55 |
in ebuild. |
56 |
|
57 |
Regards, |
58 |
igli. |
59 |
---- |
60 |
* After all, you only add the bug id once, when you're adding the patch and |
61 |
are well aware of what bug/s you're working on; it's not an ongoing burden. |
62 |
-- |
63 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |