| 1 |
On 23-03-2009 11:41:08 +0100, Sebastian Pipping wrote: |
| 2 |
> People split into three groups: |
| 3 |
> |
| 4 |
> - Friends of ${P}-fix-issue.patch naming |
| 5 |
> - Friends of ${PN}-fix-issue.patch naming |
| 6 |
> - Friends of ${PN}-1.2.3-fix-issue.patch naming |
| 7 |
> |
| 8 |
> Qualities |
| 9 |
|
| 10 |
[snip] |
| 11 |
|
| 12 |
I think what's missing is the following observation: |
| 13 |
|
| 14 |
${PN}-fix-issue.patch naming is bad if you patch code that is (likely) |
| 15 |
to change in newer releases. This is almost always the case. Ultimate |
| 16 |
example, patch something in ffmpeg or mplayer, and the next snapshot |
| 17 |
will break the patch. (i.e. doesn't apply any more.) Using |
| 18 |
${PN}-fix-issue.patch in this case gets you into |
| 19 |
${PN}-fix-issue-2.patch, which IMO is ugly. |
| 20 |
|
| 21 |
If patches are named this way, they probably fall in the case where the |
| 22 |
code it patches is unlikely to change. (assumption) |
| 23 |
|
| 24 |
> Possible solutions |
| 25 |
> |
| 26 |
> - *Communicating* your likes to all co-maintainers |
| 27 |
> in hope the will respect and remember your agreement |
| 28 |
> |
| 29 |
> - Add a related local comment (*documenting*) to ebuilds |
| 30 |
> and expect other developers to act accordingly on a bump |
| 31 |
|
| 32 |
probably best solution |
| 33 |
|
| 34 |
> - Making a GLEP *enforcing* on of these and make people |
| 35 |
> vote on which |
| 36 |
|
| 37 |
very bad one. |
| 38 |
|
| 39 |
|
| 40 |
-- |
| 41 |
Fabian Groffen |
| 42 |
Gentoo on a different level |
Archives