| 1 |
Fabian Groffen wrote: |
| 2 |
> I think what's missing is the following observation: |
| 3 |
> |
| 4 |
> ${PN}-fix-issue.patch naming is bad if you patch code that is (likely) |
| 5 |
> to change in newer releases. This is almost always the case. Ultimate |
| 6 |
> example, patch something in ffmpeg or mplayer, and the next snapshot |
| 7 |
> will break the patch. (i.e. doesn't apply any more.) Using |
| 8 |
> ${PN}-fix-issue.patch in this case gets you into |
| 9 |
> ${PN}-fix-issue-2.patch, which IMO is ugly. |
| 10 |
> |
| 11 |
> If patches are named this way, they probably fall in the case where the |
| 12 |
> code it patches is unlikely to change. (assumption) |
| 13 |
|
| 14 |
Good point. In that case the patch "revision" 2 in |
| 15 |
"${PN}-fix-issue-2.patch" actually stands for |
| 16 |
"${PN}-fix-issue-1.2.4.patch" where "1.2.4" is the |
| 17 |
version of the new package. Therefor we effectively |
| 18 |
${PV} from the begining to the end. |
| 19 |
|
| 20 |
So a conlusion from this would be that ${PN} is not |
| 21 |
suited for all ebuilds and therefore should not be |
| 22 |
standard alone if at all? |
| 23 |
|
| 24 |
|
| 25 |
|
| 26 |
Sebastian |
Archives