Separate ldns replacement package

[mozzieongit]

Split out the ldns symlinks into a separate package that obsoletes ldns. This way users can have both on their system in case they use ldns tools we haven't implemented yet and can install this extra package to replace ldns with dnst.

"Successful" run: https://github.com/NLnetLabs/dnst/actions/runs/21283165440 (updated)
(Originally packaging was failing because the dnst package in the proposed repo has conflicting files to the new dnst-ldnsutils package: trying to overwrite '/usr/share/man/man1/ldns-update.1.gz', which is also in package dnst 0.1.0~rc2-1jammy). I removed the proposed repo from the pkg-test; packaging now fails with because there is no old dnst available to install)

Another successful run: https://github.com/NLnetLabs/dnst/actions/runs/22715606884

Obsoletes: #141
Fixes: #132

[ximon18]

What is the story regarding users of the Cascade alpha releases who already have the cascade-dnst package installed, or users who already have the existing dnst package installed?

For users who already have the existing dnst package installed they will already have ldns-xxx symbolic links to the available dnst equivalents, and the prerm script will remove those on upgrade to a newer version of dnst. The new postinst script will not recreate them, so they will have lost those symlinks. I also don't see a suggests entry that would enable users to get dnst-ldnsutils as part of installing dnst if wanted. This requires such users to know that there is now a new dnst-ldnsutils package to replace their mysteriously missing symbolic links. Can / should we do better here? (or am I misinterpreting the behaviour that will result from the changes in this PR?)

For users who already have the existing cascade-dnst package installed, they will not benefit with these changes from any future versions of dnst keyset. This issue was caused by an earlier change to dnst but isn't solved by this PR. When we release a new version of Cascade we can make it depend on dnst rather than cascade-dnst, maybe that is enough because users of cascade-dnst didn't even choose to install it themselves but received it as part of installing Cascade. The Cascade installation might also have to deal with updating the Cascade config file to refer to the newly installed dnst instead of the previously installed cascade-dnst, especially if the new dnst package were to obsolete the cascade-dnst package, but I don't see any changes to do that?

[Philip-NLnetLabs]

Can we treat dnst as alpha and just put some text in release notes? Same goes for Cascade. No need to spend too much time on backward compatibility.

[ximon18]

Can we treat dnst as alpha and just put some text in release notes? Same goes for Cascade. No need to spend too much time on backward compatibility.

Ah indeed it seems that we never actually released a proper version, I thought we did. Looking at packages.nlnetlabs.nl I see only alpha and rc versions.

[Philip-NLnetLabs]

I think one goal for dnst is that it can replace the ldns utilities that we care about. So I think it should stay in alpha until we get at least to that level. Though it will get a bit more tricky with a production release of Cascade.

[mozzieongit]

Indeed. I'd put stuff in the release notes. dnst was never really released.

Re: cascade-dnst: We'll depend on dnst in the future, which means that cascade-dnst will be an orphan and cleaned up by commands like apt autoremove. Here we just have to add another release note along the lines of: if you used the alpha, start from scratch or update your config file to use dnst.

[mozzieongit]

I think one goal for dnst is that it can replace the ldns utilities that we care about. So I think it should stay in alpha until we get at least to that level. Though it will get a bit more tricky with a production release of Cascade.

I don't think dnst as a whole needs to be alpha. We just need to be clear about which tools we already re-implemented. And for people wanting to switch already (that don't need the missing tools) we provide the dnst-ldnsutils package.

The initial release was only planned to have a selection of tools and we never talked about it being an alpha at that stage. We just realized that we need to hold off of automatically deleting ldns.

[Philip-NLnetLabs]

In my opinion, a release version has to be feature complete. Right now we can easily have a separate package for the ldns compatibility programs because it is still alpha. Otherwise we would have to worry about breaking people's setup. We just make our lives a lot harder by declaring it release.

[mozzieongit]

Ok. I also asked Alex for his opinion:

dnst is/stays in alpha for the time being.