[EMAIL PROTECTED] writes:
> 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.
Ok, this only makes sense if (and as long as) you are both Debian
mainainer and lead upstream developer, so let's take this as granted.
In this case you *may* choose to produce maintain a deb without a
Debian version (a "native" package). You should be aware that fixing a
bug in debian/rules will force you to up your version number, but
that's not so big a problem in my mind.
I don't think that you need to release this new version to the world
at large. Even if you did, that would not be a big deal -- there are
plenty of bugfix releases around which say "if you don't use
that-and-such feature, there's no pressing need to upgrade".
FWIW, nobody, can guarantee whether or not "there will ever ever be
non-Debian releases" in the free software world. By that reasoning,
apt must be non-native because it's re-released with rpm suppport by
an outside party.
> Another package is gimp-print. [...] however, in this case I don't
> want to tie the debian releases to the upstream releases.
Sure, that's also valid. If you can't, or don't want to couple release
schedules, a Debian version suffix is the way to go.
--
Robbe
signature.ng
