blob: ee28e3369c2fe8fb03ea42ce570bef4d5f1bd74a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
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.
|
