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

Tomas Krizek tomas.krizek at nic.cz
Mon Mar 26 11:07:39 UTC 2018


On 2018-03-23 22:55, Daniel Kahn Gillmor wrote:
>> 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.

Good to know!
> 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.

That's a good point. It's definitely useful to be able to make packaging
changes without the need for an upstream release. We'll just keep the
packaging files in distro/deb/*, so it doesn't cause any conflicts.

> 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?

I don't think it's necessary to mirror the debian branches to upstream.
I'm primarily concerned about keeping the upstream packaging files in
sync with debian.

Since we want to provide functional debian packages in our upstream
repos along with every release, most of the packaging work has already
been done when a new version is released.

1. How do we get these changes from upstream to debian?
It'd be good if you could take a look the changes in the upstream
packaging files (distro/deb/debian/) when preparing a debian release and
sync these changes to debian. In case additional changes are needed
(e.g. for policy reasons), then these can be made in debian downstream.

2. How do we get the changes from debian to upstream?
- Let's say you decide to make some significant changes or clean up.
It'd be great if this work could be done in upstream files, which would
then get synced to debian during the next release.

- The smaller changes or policy requirements can be handled separately
in debian downstream. I could keep an eye on the debian repos and modify
our upstream files accordingly every now and then.

Would this approach work for you?

-- 
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495  C509 A1FB A5F7 EF8C 4869

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-dns-devel/attachments/20180326/c06a13f1/attachment.sig>


More information about the pkg-dns-devel mailing list