[Pkg-dns-devel] backporting knot-resolver

[ondrej at sury.org]

This is needed for API that exposes supported algoriths instead of 
hardcoding them.

O.


On 30 November 2017 23.18.05 Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

> On Mon 2017-11-13 11:30:24 +0800, Daniel Kahn Gillmor wrote:
>> On Mon 2017-11-13 03:06:09 +0100, Ondřej Surý wrote:
>>>> So i'd rather build the eventual stretch backport (assuming we can get
>>>> 1.5.0 to migrate to testing) directly off of master, if that's possible.
>>>
>>> That make sense to me, but I will need a debhelper9, python2 branch
>>> available as well.
>>
>> yep, i'm fine with having a "lowest-common-denominator" backports branch
>> -- i think that's a good idea.  But i don't want to use it for distros
>> (like stretch) that don't need it :)
>
> ok, i'm finally getting around to looking into backporting 1.5.0 to
> stretch, and i'm running into:
>
> commit 552a4709a4ae2f467f194a44c8c65d46a43e8b14
> Author: Ondřej Surý <ondrej at sury.org>
> Date:   Fri Sep 29 19:56:11 2017 +0200
>
>     Bump required libknot version to >= 2.6.0
>
> diff --git a/debian/control b/debian/control
> index 0aa42c20..93ace3af 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -14,7 +14,7 @@ Build-Depends: debhelper (>= 9),
>                 libgnutls28-dev,
>                 libhiredis-dev,
>                 libjansson-dev,
> -               libknot-dev (>= 2.3.0),
> +               libknot-dev (>= 2.6.0),
>                 liblmdb-dev,
>                 libluajit-5.1-dev,
>                 libmemcached-dev,
>
>
> however, Makefile's KNOT_MINVER is 2.3.1.  so i'm not sure what to make
> of this.  Is there a reason for the stronger version bump?  2.6.0 is not
> in stretch (or in stretch-backports), so that makes this a much higher
> hurdle to backporting than otherwise.
>
> Any objection to my bumping this back down to match KNOT_MINVER ?
>
> It would be helpful if any future changes that bring this build-dep out
> of sync with KNOT_MINVER, the commit message could contain a pointer to
> the discussion or decision-making process that led to it!
>
> for now, i'm going to go ahead with the revised build-dependency (rather
> than take on backporting libknot as well), but please let me know if
> there's a good reason i should avoid doing that.
>
>     --dkg