Re: Incorporating patches best practice
Gary Briggs <firstname.lastname@example.org> writes:
> The FLTK maintainer submitted a bug today to let me know that he's
> created a change that will impact me:
> In the email, he attached a patch.
Until upstream releases a new version with that patch applied, then it's
a separate patch IMO.
> 1) Obviously not appropriate in the general case, but I could do a
> major new release, since I've added a couple of big features since the
> last deiban package.
A new release of the same upstream version? Sure, but any changes would
be distinct from the upstream version still.
> 2) Re-package the current package, but include the one patch, and ramp
> the debian version suffix [to 0.16-2]
That sounds like the right option. The patch can go in ‘debian/patches/’
until upstream releases a new version which incorporates it.
> 3) Re-package at the current version and ramp the debian version
> suffix, but include the patch directly in the source; basically,
> change the main source tarball to be the current svn version.
That would be a lie: you would be claiming the source is what upstream
calls version 0.16, but it's not.
> Of course, that would include the major changes I've made since I
> officially released 0.16...
If you've been making changes that make your release different from the
upstream version, they should be applied as patches to that version.
Please don't modify the source of an already-released version directly
to apply your changes.
> I suspect that the best answer is #2, but that feels a little hokey
> when I'm the upstream as well as the package maintainer.
You need to wear different hats :-)
For more on how to be an upstream which makes Debian's work easier, see
<URL:http://wiki.debian.org/UpstreamGuide> and especially
\ “I have yet to see any problem, however complicated, which, |
`\ when you looked at it in the right way, did not become still |
_o__) more complicated.” —Paul Anderson |