Re: Advise on packaging a new Python module
On 07/11/12 16:06, Tomás Di Domenico wrote:
> On 07/11/12 16:43, Jakub Wilk wrote:
>> * Tomás Di Domenico <tdido@tdido.com.ar>, 2012-11-07, 12:30:
>>> About the different versions in the git repository and the upstream
>>> package, that is actually my fault. I checked out the code from the
>>> upstream Mercurial repository and built the tarball myself, hence
>>> using a more recent version than the one in the tarball.
If you find yourself needing to do that, you should indicate it in the
version number (e.g. see ioquake3_1.36+svn2287.orig.tar.gz) rather than
claiming that your orig.tar.gz is the upstream release (e.g. 1.36 here).
For svn, commit numbers are useful; for git, the number of commits since
the tag is a useful thing to use in version numbers (as done by, e.g.,
git describe).
> I believe I have seen Debian packages that include revision
> numbers in their version numbers. I was wondering what would be a
> scenario where you'd actually build the Debian package with a upstream
> revision that's newer than an official release, and if this happens often.
I use snapshots of ioquake3 to have a codebase that's somewhere close to
the one that OpenArena's fork is based on (we use a shared ioquake3
engine, not the forked version, in Debian). 1.36 was released in April
2009, so it's far too old for current OpenArena.
It also means we have some sort of hope for security support - upstream
don't make security or bugfix releases, only infrequent feature
releases, but they do fix security bugs in svn and announce which
commits are necessary for security. Trying to backport security fixes
past 3.5 years of development isn't ideal; supporting one recent-ish
snapshot per major Debian release limits how far back we need to go.
I do not recommend this approach, but if your upstream makes it
necessary, there might be no alternative.
S
Reply to: