[Pkg-dns-devel] Tracking packaging files for knot / knot-resolver in upstream

[Daniel Kahn Gillmor]

Hi Tomas--

On Wed 2018-03-21 10:59:51 +0100, Tomas Krizek wrote:
> I'm the rpm maintainer for these packages, but my experience with debian
> packaging is very limited. However, I was able to produce functional
> debian packages by using the files from unstable debian and making a few
> modifications.

I'm glad you've been able to do this :)

> I'm reaching out to you, because I'd like to ask for your help with
> maintaining these debian packaging files. I think it'd be best if the
> packages we provide in upstream resemble as closely as possible the ones
> that are in unstable debian.

i agree that this is the right approach as well.

> 1. Downstream patches - these are very costly to maintain, as they
> require frequent re-bases when files are changed or moved around. It'd
> be best if we could eliminate these entirely if possible. I've managed
> to eliminate all patches for knot and there's an ongoing effort to
> remove/clean up patches for knot-resolver as well [4].

I agree that carrying patches in the distros is a point of pain, and i
would be happy to be able to get rid of them.  I generally send all of
my straightforward patches upstream anyway, and only keep
debian-specific patches "downstream" that seem like they would be too
intrusive to make upstream.  i've noticed your upstreaming even some of
those i thought would be too intrusive by making them into
configuration-time options.  thanks for that!  I'm happy to try to take
that approach in the future.

> 2. *.symbols file - I understand why it's required for stable releases
> and I believe we'll be updating this file in our stable upstream
> releases. However, updating the symbols file for development snapshots
> is time consuming and I don't really see the value in doing so. It seems
> to be required by the debian policy, but it doesn't seem to have effect
> on the function of the package. My idea is to prepare the development
> snapshots without the symbols file [5].

The symbols file is for integration with the rest of the distro.  If
your development files are shipping in a standalone apt repo that is not
integrated with the rest of the distro, and it is not expected that they
will be used to develop an integrated distro, it seems fine to me if
to drop the symbols file from your development packaging.

We will not drop the .symbols files from the releases that make it into
debian unstable, though -- we want to make distro integration work :)

> In general, it'd be great if we could keep knot / knot-resolver
> consistent between the various distros -- including paths to binaries,
> libraries, systemd unit files, tmpfiles, user names etc. We've done a
> major cleanup for knot-resolver 2.0 and it'd be great if we could
> continue in this direction in the future.

yes, this work has been really great, and is much appreciated!

> Finally, we'd be very grateful if you could contribute debian packaging
> changes to upstream. Perhaps it could even be possible to move most of
> the packaging work there and re-use the upstream packaging files for
> downstream packaging. That's mostly the approach I went with for rpm
> packaging and it works quite well.

So i have some experience with having the debian/ packaging in the
upstream repository -- as well as with being both upstream and a debian
maintainer for a given package.

fwiw, i do *not* think that it makes sense to have debian/ on the master
branch of any development repo, or shipped in debian/ in the upstream
tarball.  doing so makes it more difficult than it needs to be to ship
minor packaging updates in debian, because there are collisions and
minor differences between the packaging for debian proper, for ubuntu,
for your development packaging, etc.

The reason i prefer them to be separate is because there are often
things that come up for debian itself -- changes in dependencies,
changes in policy, new diagnostic tools, all of which are best dealt
with by a revision to the debian packaging, but *not* with a new
upstream release.  keeping the packaging separate (but closely aligned)
facilitates better system integration.

My general preference is for all packaging/system-integration work to
live on a git branch that merges regularly from the upstream branch.  In
the typical case, i merge from the upstream branch at release time.  and
if there are officially published-and-signed tarballs, then i try to
ensure that we have those captured as well, using a pristine-tar branch.

My approach to branch naming is to use the style recommended by
[DEP-14].  If there are concerns about this approach, or suggestions for
changes, i'm happy to hear them.

All that said, i'm happy to mirror the debian/master branches that are
currently in the repos at https://salsa.debian.org/dns-team/ on the
cz.nic git repos as well.  and i'm also happy to push to those repos
whenever i push a debian release, if you'd like.  would that address
your concerns, or do you want to try to do some sort of tighter
integration?

thanks very much for your work on knot and knot-resolver upstream, i
look forward to collaborating more with you on it!

     --dkg

[DEP-14] http://dep.debian.net/deps/dep14/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-dns-devel/attachments/20180323/0cd041c8/attachment.sig>