Yo Santiago (CC'd), could you please drop your opinion on this for extra
reference?
On 4/30/24 18:34, Daniel Baumann wrote:
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.
We currently have v5 and v6 packages in a single knot-resolver repo on
pkg.labs.nic.cz and v5 users are safe to `apt update` from the repo
without breaking their setup or they can `apt install knot-resolver6` to
upgrade. This would apply to Bookworm -> Trixie transition as well.
If there was no distinction between v5 and v6 packages, unwanted updates
leading into broken setups are bound to happen, that's not very user
friendly. I could split the upstream repos (knot-resolver5,
knot-resolver6), but that won't solve Bookworm -> Trixie case.
OTOH knot-resolver6 fork is extra maintenance (new source package &
Salsa repo...) and an unwanted irregularity although it gets the job
done. This was the case for bird2 and upcoming bird3 for example, which
also isn't a library.
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?
I don't think that's worthwhile, that's why it's not officially supported.
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
Consulting with upstream, there doesn't seem to be a strong reason not
to merge like that. Separating the python module(s) in a sub-package
could be useful in some (official unsupported edge) cases like
containers where pulling the extra python deps might increase the image
size significantly.
I believe vast majority of users will use the manager so it's desirable
to install it by default, which would be 100 % ensured by having it a
part of knot-resolver package, so that's a plus.
Those who want to use kresd without manager can simply disable manager
and do what they want at the cost of some unused python deps. I don't
think that's too bad of a compromise.
So I'm generally in favor of merging the -manager package, I'm just
worried about unwanted upgrades if we don't change the name
(knot-resolver6) as there isn't really an upgrade path. Such is the
price of progress.
Note that Fedora policies/customs are strongly in favor of not forking
per-version - in line of what you suggest.
Note that -dbg packages are generated automatically and don't need to
be specified in control (I'll provide a commit for that).
Oh, right :)
Cheers,
Jakub
