Re: No native packages?
* Guillem Jover <email@example.com>, 2013-02-02, 13:56:
if you are going to patch the package you might as well do the one
line change from "3.0 (native)" to "3.0 (quilt)", and rename the
source tarball to add «.orig».
That's a good solution for derivatives, not so much for NMUs or
As I mentioned on my previous mail, I consider that a nice feature. To
me NMUing or backporting a native package is the equivalent of an
external and uninvolved person to send a mail to, say, the postgresql
developers, telling them that you've released a new version of the
upstream project for them... on the upstream server.
Taking into account that the distribution archive and BTS are the
hosting site for the native package, an NMU is a versionspace and file
release takeover, and stomps over previously released versions and
supercedes them, which might be confusing for downstreams (like
non-derivatives), as the NMU might end up being rejected, or
reimplemented in a different and incompatible way, etc.
So what do you propose instead? It's not like native packages get NMUed
because of great entertainment value of the NMU process, but because
there's no better choice.
(Random data point: I have 14 packages with versions indicating they are
NMUed native packages installed on my system. Some of them have priority
standard or higher.)