From 3050ea58ec5f7f1d5a3d70a080a9cb9dceadda38 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 27 Apr 2024 12:36:23 +0200 Subject: Adding debian version 3.0.5-1+deb11u1. Signed-off-by: Daniel Baumann --- debian/TODO | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 debian/TODO (limited to 'debian/TODO') diff --git a/debian/TODO b/debian/TODO new file mode 100644 index 0000000..ee28e33 --- /dev/null +++ b/debian/TODO @@ -0,0 +1,32 @@ + * package python3-libknot + + * add more autopkgtest tests + - set up and run an authoritative resolver + - do dnssec signing + - validate the signatures + + * consider making the modules dynamic instead of static. i see three + possible approaches: + + a) each module could ship in a separate package, and would drop + into the path identified by --with-moduledir= + (/usr/lib/$(DEB_HOST_MULTIARCH)/knot/ , currently). They would + be automatically loaded by knotd as long as the packages were + installed. + + b) we could ship them all directly in the knot package. they would + live in /usr/lib/$(DEBHOST_MULTIARCH)/knot-$(VERSION)/ in this + case, and the admin would need to manually load them in + knot.conf. + + c) we could ship them in a separate knot-modules package (one + bundle of all modules, located in the same place as (b)). the + admin would need to manually load them in knot.conf. + + In either (b) or (c) we might want to change --with-moduledir to + point to somewhere that the admin is encouraged to edit, like + /etc/knot/modules or something. or maybe we should abandon + --with-moduledir entirely? + + Transitioning from static to dynamic modules seems like an awkward + process, though. -- cgit v1.2.3