Re: git-buildpackage and tarballs
On 10/23/2011 11:37 AM, Charles Plessy wrote:
> Hi Russ,
> I think that we are discussing two separate questions: whether a maintainer of
> his own software in Debian should release a new upstream version when updating
> the Debian package
If the change in the software isn't located in the packaging,
then answer is yes. Otherwise, just increase the debian
specific release number and don't re-upload the orig.tar.gz.
> and whether the the maintainer of a Debian package for
> which there is no upstream tarball can use a native format or not.
>
That's *never* the reason to choose the native format.
> There is no need to trigger update on other systems
> when the changes only affect Debian. But note that it is difficult to draw a
> line anyway.
Why is it difficult? If you think it is (I don't think it is), then just
increase always the upstream version, if that is more easy for
you to do like this. That's what I do in all software that I maintain
in Debian and for which I'm also upstream. It always works.
But anyway, this has nothing to do with using the native format
or not.
> Among the packages I maintain, some show new upstream releases in
> my radar, which fix Windows or Mac OS issues only. Some other project I
> maintain has a friedly version scheme, where the most minor number indicates
> changed relevant to the MinGW port only. All of this is upstream decisions on
> which we can not give more than opinion and guidance.
>
Of course you can voice your opinion to upstream! And guess
what? Most of the time, they are very distribution friendly, and
will accept to change the way they use version numbers! :)
> The point that I would like to make, is that when there is no upstream tarball,
> whatever the reason, the dpkg native format is a natural choice for a Debian
> package.
NO!
Let's say you have a package with an init script. In Ubuntu,
they will want to remove that debian/init script, and write an
upstart script instead. In their case, they just keep your
orig.tar.gz file, and just change a tiny bit of Debian packaging
each time they import your package. By choosing to use a native
format, you are forcing them to do ugly things with the version
numbers that they could avoid otherwise.
And an init.d script is only one out of many examples which you
have as a difference in packaging a package for Debian or for
Ubuntu. I could also have talked about:
- differences in dependencies
- differences in the maintainer field
- differences in release names in the debian/changelog
- differences in user/group names
And there's even more reasons, like allowing all DDs to do an
NMU in a normal way to correct an RC bug during the distribution
freeze (or a bug squashing party), for example, but not willing to
touch your upstream code or version, etc...
So your point about upstream not doing a tarball isn't the reason
to choose the native format. Just forget it!
> I am aware of
> Develpers Reference's §6.7.8.1.2, but I do not think it is widely followed
IT IS followed whenever possible. In rare cases, when upstream
really does silly things with his original tarball, then you have
to recreate the tar.gz, but that's pretty rare. If there's no
upstream tarball, and just a VCS, then you should do something
like this:
example-software_0.1.2+20111023.git.orig.tar.gz
You are free to use another scheme, like using the SVN
checkout number, or use tag names if you see fit, but
adding the date and the CVS name is a commonly accepted
naming scheme for such case.
Thomas Goirand (zigo)
Reply to: