Currently, hackport will overwrite an ebuild if it shares the same version as what it is grabbing from Hackage. For instance, this will overwrite diagrams-svg.1.4.3.1.ebuild if it already exists
$ hackport merge diagrams-svg-1.4.3.1
...
Writing diagrams-svg-1.4.3.1.ebuild
This may sometimes be the preferable option, as it may not be necessary to cause rebuilds for the package in question if it is a very minor update (for instance EAPI or DEPENDS). However, often times a portage revision bump is desirable, so in this case it should write diagrams-svg-1.4.3.1-r1.ebuild.
Similarly, a revision for the version in question may already exist. In this case, hackport will still output an ebuild without any revision number, which requires the developer to manually rename it. For instance, if diagrams-svg-1.4.3.1-r2.ebuild already existed, it would output to diagrams-svg-1.4.3.1.ebuild instead of a -r2 or -r3 ebuild.
It would be convenient if hackport:
- recognized portage revisions and knew how to create a revision bump or overwrite an existing revision
- contained some logic of when it should create a revision bump vs. overwriting
Currently,
hackportwill overwrite an ebuild if it shares the same version as what it is grabbing from Hackage. For instance, this will overwritediagrams-svg.1.4.3.1.ebuildif it already existsThis may sometimes be the preferable option, as it may not be necessary to cause rebuilds for the package in question if it is a very minor update (for instance
EAPIorDEPENDS). However, often times a portage revision bump is desirable, so in this case it should writediagrams-svg-1.4.3.1-r1.ebuild.Similarly, a revision for the version in question may already exist. In this case,
hackportwill still output an ebuild without any revision number, which requires the developer to manually rename it. For instance, ifdiagrams-svg-1.4.3.1-r2.ebuildalready existed, it would output todiagrams-svg-1.4.3.1.ebuildinstead of a-r2or-r3ebuild.It would be convenient if
hackport: