First Alpha Release of PowerDNS Recursor 5.0.0.

[omoerbeek]

https://blog.powerdns.com/2023/09/13/powerdns-recursor-5-0-0-alpha1-released

[omoerbeek]

Some people already build experimental packages for various platforms. Very good! Some notes after feedback received:

• The build needs cargo and rust as a build dependency.
• Currently, when building form the src tarball the build requires python, as it runs $(PYTHON) generate.py as a step to generate a few source files. This is a bit of a nuisance, alpha2 will move that step to before building the tarball and including the generated files in the tarball.
• The python dependency is not explicit. If python is missing the build fails with the error below.

make[3]: Leaving directory '/wrkdirs/usr/ports/dns/powerdns-recursor-devel/work/pdns-recursor-5.0.0-alpha1/ext'
Making all in settings
gmake[3]: Entering directory '/wrkdirs/usr/ports/dns/powerdns-recursor-devel/work/pdns-recursor-5.0.0-alpha1/settings'
: generate.py
gmake  all-am
gmake[4]: Entering directory '/wrkdirs/usr/ports/dns/powerdns-recursor-devel/work/pdns-recursor-5.0.0-alpha1/settings'
gmake[4]: Nothing to be done for 'all-am'.
gmake[4]: Leaving directory '/wrkdirs/usr/ports/dns/powerdns-recursor-devel/work/pdns-recursor-5.0.0-alpha1/settings'
gmake[3]: Leaving directory '/wrkdirs/usr/ports/dns/powerdns-recursor-devel/work/pdns-recursor-5.0.0-alpha1/settings'
Making all in settings/rust
gmake[3]: Entering directory '/wrkdirs/usr/ports/dns/powerdns-recursor-devel/work/pdns-recursor-5.0.0-alpha1/settings/rust'
gmake[3]: *** No rule to make target 'src/lib.rs', needed by 'libsettings.a'.  Stop.
gmake[3]: Leaving directory '/wrkdirs/usr/ports/dns/powerdns-recursor-devel/work/pdns-recursor-5.0.0-alpha1/settings/rust'

Some package build infrastructures require offline builds. For that, the needed Rust dependencies need to be available. Debian packages these, but other build systems require pre-downloaded crate sources. This can be done by vendoring the dependencies, a sketch of the procedure.
On a online system:

1. untar src tarball and cd to it
2. Download dependencies. For that to work, we need te
   generate a few (Rust) files first (this will be avoided in the alpha2 release):

$ autoreconf -vi
$ ./configure ...
$ make -C settings   # Generates Rust file in settings/rust/src
$ cd settings/rust
$ cargo vendor # Download depencency sources to a new vendor dir

Make the vendor directory available on your offline build machine and tell cargo to use
the dir:
3. Add a .cargo/config file to the project dir in settings/rust:

$ mkdir .cargo
$ cat > .cargo/config << EOF
[source.crates-io]
replace-with = "vendored-sources"

[source.vendored-sources]
directory = "vendor"
EOF

4. With the vendor directory and the .cargo/config file cargo will use
   the vendored dependencies without needing to download them from the
   net.

[paddg]

Yes, I can confirm it works this way. The pdns-recursor-5.0.0-alpha1.tar.bz2 file has become significantly larger: 1,6M -> 8,7M. Do you plan to ship the file in this form in the future?

[omoerbeek]

Not decided yet. The package infrastructures I've seen so far have ways to download the crates before building or provide them as packages themselves (like Debian is doing). Incorporating the crates into the recursor tarball would burden everybody and bypass whatever method the package infrastructure offers, which I'm sure would not be appreciated by everybody.

[paddg]

With this setup the building/packaging on Suse was successful: https://build.opensuse.org/package/show/home:paddg/powerdns-recursor-test

[paddg]

A small problem is that "obs-service-cargo_vendor" cannot handle bz2 compression, only gz, xz and zst are allowed. However, the Recursor source code ships as bz2

[paddg]

@omoerbeek, @uncomfyhalomacro has fixed the lack of obs-service-cargo bz2 support for us.

[zeha]

Questions:

• Should 5.0.0 packages ship a .yml config instead of the old .conf config?
• Should 5.0.0 packages attempt to automatically convert conf -> yml on upgrades?

[omoerbeek]

• Ideally, new installs should start to use YAML. We have to figure out how to achiev that while not disturbing extsing (old-style) configs.
• There's no automatic conversion (yet). I hesitate to modify configs without confirmation from the admin.

[rgacogne]

* There's no automatic conversion (yet). I hesitate to modify configs without confirmation from the admin.

IMHO we shouldn't automatically convert, but provide the means (tool) to do so, document when the old configuration is expected to go away and perhaps warn that it would be wise to switch to the new configuration.

[zeha]

Unfortunately "new installs use YAML" and "old installs keep whatever" is (I think) a problem for Debians packaging.
Both the .yml and .conf would typically end up being "dpkg conffiles", and upgrades would automatically get the .yml installed.

I think the 'clean' thing what the debs could do is:

• install .yml as dpkg conffile, always
• stop installing .conf as dpkg conffiles
• on upgrades, detect .conf, convert to .yml and remove the old .conf dpkg conffile

Maybe there are variations on what can be done, don't know yet.