Chris Danis <[EMAIL PROTECTED]> wrote: >What exactly is a Debian-native package? I've seen definitions from "a >package with no upstream source" to "written especially for Debian," >which seem kind of orthogonal to me. Here's my situation: > >I'm in the NM queue, currently packaging tclbabel, a piece of software >I have written myself. Because I am both upstream and possibly Debian >maintainer, should this be such a native package?
Aside from what everybody else has said, it's also worth considering that - especially if it's not specific to Debian, which it doesn't sound like it is - at some point in the future you might decide to hand the packaging off to someone else. At that point, it's good to have had the packaging separate from the start. A lot of people don't like keeping debian/ directories in upstream CVS for this reason. For example, I have CVS write access upstream for two of the packages I maintain, but I prefer to keep debian/ out of that for a reason that might be best described as "separation of powers". There are a few packages in the distribution with a debian/ directory in the .orig.tar.gz and then a diff to *that* in the .diff.gz - I think it ends up being pretty messy. Sometimes it can be an ease of management issue. Lots of work has gone into making it very easy to make releases of Debian packages, so in the early stages of a project I'll often just hack together a Debian native package for the time being. When releases with purely packaging changes are infrequent, this can make sense. As stability approaches, though, eventually the package should gravitate towards the "written especially for Debian" definition. -- Colin Watson [EMAIL PROTECTED]
