> > I think the answer is simply that you shouldn't be treating this > > as a "debian native" package. > > Why not? If no changes take place from upstream version to debian > source, tagging on "-1", and creating an empty Debianization diff is > unsound.
There's nothing wrong with an empty diff. When the upstream developer and the debian developer are the same person, it still makes sense to treat the package as a non-native package if there will ever be non-Debian releases. I'm upstream for two of my packages. One of these packages, msttcorefonts, is a script to make it easier to installing some True Type fonts onto a Debian system. I wrote the script for Debian, and it doesn't really have any other purpose. I suppose someone might be able to modify it for another distribution, but I don't have any intention to support that. Every release of this package is a Debian release, so I packaged this as Debian native. Another package is gimp-print. I'm not the primary g-p developer, but I do have write privs. on the upstream source and I maintain the Debianization along side the main development tree. gimp-print has periodic releases in .tar.gz form. These releases contain a debian subdirectory and it's possible to build a deb from them without any diff, however, in this case I don't want to tie the debian releases to the upstream releases. For example, lets say version 4.1.5 is released and I package and upload it. Let's also say that I build it using a buggy version of debhelper which screws up the dependencies and I need to recompile and upload a fixed version later. If it's native, I'm screwed, I have to wait until 4.1.6 or convince the other upstream developers to put out a new release without any real substantial changes, confusing non-debian people. If it's non-native, I just release 4.1.5-2, no problem. This sort of thing happens more often than you might think. Eric
