Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Sat, Jul 01, 2017 at 08:52:29AM -0700, Russ Allbery wrote:
[...maintaining non-Debian-specific software as a native package...]
> I certainly think it's not good practice.
I think it depends on the particulars of the situation.
I am upstream for two of the packages I maintain for Debian: nbd and
fdpowermon.
For nbd, I maintain it as an upstream package on sourceforge and github,
and as a non-native Debian package.
For fdpowermon, I just maintain it as a native package. I do this,
simply, because the package is fairly trivial -- the most important bit
is a (currently) 573-line perl script (and that's including POD
documentation). While it's certainly possible to ship an "upstream"
Makefile.PL or some such with this package, that feels like overkill and
generally not worth it. Additionally, the packaging is so simple that
updating the package for just the packaging is rare, if it even happens
at all, so just about every update I've ever done was relevant for
people who did not use Debian, too.
While I agree that Debian is not a general software distribution
platform, and that therefore shipping software like this isn't
necessarily a good idea, for me as a Debian developer it is
significantly easier to just maintain it this way and not have to worry
about the extra overhead (even if it's a pretty small overhead) that an
"upstream" release would involve.
[...]
> 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.
I can see why that might be the case, but given that in the case that I
quote above that is actually quite rare, I'm not sure it's a problem.
> 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.
I'm not sure this is true.
By uploading a native package into Debian, I take the "risk" that at
some point someone will have to do an NMU, yes. Indeed, if I instead
hosted the package on some upstream hosting site, then nobody but me
will be able to do releases of fdpowermon. But that's not a major issue;
I trust that my fellow developers won't abuse that right (indeed, they
don't usually do so).
If I ever find myself in the situation where I stop maintaining
fdpowermon in Debian but continue maintaining it upstream, then
converting the package from a native to a non-native one is fairly
trivial. In fact, I've occasionally uploaded nbd as a native package by
accident, because dak doesn't actually care, and neither do our build
tools (when using source format 1.0). As such, if that situation ever
happens, then moving to a non-native package is trivial, and there is no
awkwardness.
[...]
> 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.
Indeed; for nbd, I've occasionally had to do that as well. Usually it's
a cherry-pick from upstream master or some such, where a bug was first
exposed in one of our more obscure ports; and while I do want to release
it upstream, just doing a new upstream release just so I can release a
bugfix for alpha or hurd or whatnot isn't really worth it.
For a simple perl script which by its very nature has little portability
issues and therefore small chances for requiring such patches, I don't
think it's worth fussing about though.
A somewhat more complicated example is ikiwiki; when Joey was still
maintaining it for Debian (before he resigned from the project), it was
also a native package. At the time, the package version number was just
the git checkout date, as in, "we don't really do upstream releases,
what's in Debian is just a snapshot from the git repository". That, too,
seems like a reasonable approach to me.
I guess what I'm saying is that it really depends on the particulars of
how you maintain the software; and that while in general it's probably a
bad idea, there can be corner cases where it isn't necessarily a bad
idea, can even be a good idea, and certainly takes away some overhead
and extra work that wouldn't be necessary at all if not for the fact
that you're doing a non-native version and therefore need to do an
"upstream" release before you can do a Debian release.
Regards,
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Reply to: