[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
Description: PGP signature
