On Sun, 02 Jul 2017 at 01:28:59 +0200, Wouter Verhelst wrote:
> 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.
It still is. I am the Debian maintainer and an upstream co-maintainer,
and in practice the only upstream releases since I took over Debian
maintenance have been released by me, so I haven't yet taken on the
extra release bureacracy involved in making an upstream release and a
separate Debian release. The upstream website points to Debian as its
way to distribute tarballs (although using a git clone is recommended
for those building from source).
One of these days I'll try doing an upstream release and an accompanying
non-native Debian release, although that is complicated by the fact that
Joey uses debian/changelog as an upstream changelog in software for which
he is the upstream (see etckeeper and git-annex for how other maintainers
have dealt with that).
> 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".
ikiwiki does have releases. They are usually of the form major.minor
where the major version tracks (major) compatibility breaks, and the
minor version happens to be the release date. When a branch with smaller
updates is needed, it gains a micro version number. The same is true
for other packages released by Joey, in particular git-annex.
> 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.
Some thought experiments which might help to find the right line to draw:
Should dpkg be a native package? It was written specifically for Debian,
but is clearly useful to other distributions (other distributions package
it, mirroring how we package rpm). (Current state: it is native.)
Should game-data-packager be a native package? It was written specifically
for Debian, but has since grown to be able to produce non-dpkg packages.
(Current state: it is native. I have considered making it non-native,
but that would double the work involved in making a release.)
Should sysvinit be a native package? It was cross-distro once, but my
understanding is that the Debian maintainers and the upstream maintainers
of this particular fork of Miquel van Smoorenburg's System V-style init
are effectively synonymous. (Current state: it is non-native, and for
some reason the only upload by the current maintainer was versioned
like an NMU.)
S
