Sean Whitton <spwhit...@spwhitton.name> writes: > Native packages are also used for software that is intended for use > beyond Debian, but where the upstream maintainer also maintains the > Debian package. In such cases, the Debian revision and orig tarballs > represent needless overhead (tweaks to the packaging can use an > increment to the minor version number, or similar).
> Some people frown upon this practice, but there are more than one of us > that do it, so probably worth mentioning in policy as a secondary use of > native packages (possibly a footnote, due to lack of consensus? There > is certainly not a consensus that it's terrible). I thought there actually was a consensus that it's terrible. I certainly think it's not good practice. I would recommend against anyone doing this, speaking as someone who maintains lots of upstream software that I also package for Debian, and therefore would rather not document it in Policy, unless we're going to say not to do it. Bumping the minor version for things that no one cares about (because they only affect people consuming it from Debian) is probably between you and your users, although I think it's poor practice and would be vaguely irritated by it. But the stronger argument against this approach is NMUs and change of maintainership. As soon as such a package is NMU'd for whatever reason, or if you no longer have time to maintain the package for Debian but are still developing it upstream, the native package status gets really awkward. At that point, the package is diverging from upstream, but all the normal mechanisms to handle that divergence with patch sets and whatnot are no longer available. I've also repeatedly had the experience as upstream maintainer that I actually do need to carry a Debian-specific patch for a while, since Debian needs some quick fix that I don't want to take upstream in the same form. Which means that I want to use the patch handling mechanisms of Debian even for myself. And the overhead is basically nonexistent once you get your tools configured and a workflow set up. Whenever this came up on debian-mentors, it seemed to me like there was fairly strong consensus that native status should only be used for software with no independent existence, and as soon as there's a separate upstream release and Debian packaging, it's better to just do the setup work to have a non-native package. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>