Hi,
On 4/30/24 18:12, Jakub Ružička wrote:
Secondary reason for that was that there is no upgrade path from 5.x to
6.x so it's unwanted for knot-resolver 5 packages to auto-update to 6.
For that, the package probably needs a different name (like
knot-resolver6)
imho this should be handled in the package (e.g. by showing a debconf
note or so) and be included in the trixie release notes. renaming the
binary package doesn't really solve much and is more suited for
(library) transitions, i.e. if there were several knot-resolver-module-*
packages or so.
also (I haven't looked at it), is it worthwile to (with users consent)
to "try" to guess with (some parts of) the old config to generate the
new config from?
So what do you suggest?
generally, the amount of binary packages should be limited to a minimum
- oiow there needs to be a reason why an additional binary package is
added. some of them are:
* saving relative excessive amount of diskspace (e.g. large
documentation can be split into a -doc package)
* different parts have different dependencies and/or particulary
long dependency chains (e.g. gtk parts of a cli tool)
therefore, imho the following binary packages make sense here:
* knot-resolver
* knot-resolver-doc
* knot-resolver-module-dnstap
* knot-resolver-module-http
Note that -dbg packages are generated automatically and don't need to be
specified in control (I'll provide a commit for that).
Regards,
Daniel
