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) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ea39d42.5070...@debian.org
