Re: first questions
> > 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
Reply to: