On Tue, Dec 1, 2009 at 8:24 AM, Daniel Moerner <dmoer...@gmail.com> wrote: > I don't understand why you changed mlton to be a native Debian package in > version 20091015.
The debian package scripts are kept in upstream subversion. So these svn snapshot "releases" corresponds 1-to-1 with the packaging scripts used for that release. > mlton is not a package that was written specifically for Debian. AFAIK this is not the only criteria for making a package debian-native. I couldn't find a specific definition of what a "debian native" package is in the policy. I did however find this [1]: 1. Non-Native Debian Package > A non-native debian source package contains a dsc, diff.gz and an > orig.tar.gz file. > 2. Native Debian Package > The Version number for a debian native package is only the version, it > doesn't have a Debian revision number, it looks like: 2.8. > A native package contains only a dsc and a tar.gz file. > 3. When to use a native vs a non-native debian package > You should only use a native Debian package when it is clear that the > package would only ever be of use in Debian. Even if the software is > currently only available in Debian, if someone could reasonably use the > software on another distribution or on another operating system, then the > package should be non-native. > A few examples of normal packages are: libc6, apache, phpmyadmin. But > linda, lintian, dpkg and some other tools are purely developed for debian, > and make no sense being released in another distribution. > This "definition" discusses two indications that a package is debian native: a) The package has no .diff.gz b) The package is only "of use in Debian" Clearly (b) doesn't apply here, but (a) does. lintian complains when you have an empty .diff.gz file, corresponding to point (a). > Even if you do all the maintenance of upstream, it still makes more > sense to have the upstream source separate, with the Debian changes as a > patchset. Even an empty patchset? > This is especially confusing given that you're using a new upstream version > taken from svn r7263. That would suggest that the proper version numbering > would have been: > > 20070826+svn7263-1 Adding the '+svn' tag would probably be a good idea. I can't agree that calling it 20070 is a good idea, however. The version in debian atm is "r7366 | wesley | 2009-11-07 22:32:35 +0100 (Sat, 07 Nov 2009)". When/if there is finally a consensus to release a new upstream version, I think a debian revision would again make sense since I would begin maintaining an svn branch for the maintainer scripts. Perhaps 2009XXYY-r7367 to indicate the release branch 2009XXYY taken at revision r7367. I'm somewhat surprised that google doesn't turn up other people who keep the debian package scripts in the upstream repository. [1] http://people.debian.org/~mpalmer/debian-mentors_FAQ.html
