Re: No native packages?
On Sun, 2013-01-27 at 19:16:44 +0100, Jakub Wilk wrote:
> Dmitrijs Ledkovs wrote on his blog[0]:
> > Generally if software is useful in Debian Project it can be useful
> > for other debian-like and unlike projects. In particular native
> > packages do not offer the same patching flexibility as 3.0
> > (quilt), thus forcing downstream distributions to inline modify
> > packages without DEP-3 headers. This hurts us, when trying to
> > merge useful stuff from derivatives back into Debian, as changes
> > are not split into individual patches.
I don't really see the problem here, 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».
One of the issues with native packages before format 3.0, was that it
required the downstream to choose a patching system, add the patching
machinery to debian/rules and debian/control, etc, but this is now a
trivial change. It could also be pretty inconvinient if the packaging
had to diverge substantially as the debian/ directory would get in the
way, this is also not an issue anymore with format 3.0.
I was a very strong proponent of avoiding native packages for
non-Debian-and-derivatives specific software, because it used to be a
real burden for downstreams, but not so any longer. Now I just think
that while it might be convenient, it's just bad style (and I'm guilty
of this myself, as I've not yet converted libpmount to non-native, for
example).
For Debian-specific software, the point of native packages is that
at least the Debian (or any other derivative) archive and BTS are
the upstream releases and bugs site for that software, so turning
those into non-native, to me would mean having to look for external
project hosting sites for them.
> It's not only about derivatives, but also in-Debian forking, i.e.
> NMUs. NMUing native packages is quite awkward.
TBH, I've always found that to be a feature of the Debian procedures.
Thanks,
Guillem
Reply to: