Package dnst as DEB & RPM packages, and Docker images.

[ximon18]

This PR creates DEB and RPM packages for installing dnst plus ldns-xxx symbolic links. It also creates a dnst Docker image (it does not attempt to support ldns-xxx commands).

Ideally the DEB and RPM packages would either hard conflict with an existing ldns(-)utils installed package (the naming differs slightly between DEB and RPM at least in Ubuntu and Fedora repositories) or would obsolete/replace an existing ldns(-)utils installed package. For DEBs this seems to be doable, but for RPMs the support for handling upgrades is less "smart" and requires %posttrans support which Ploutos lacks (as the version of cargo-generate-rpm that it uses lacks the support, though newer (compatible with Ploutos?) cargo-generate-rpm does support it).

Relevant background info:

• https://www.debian.org/doc/debian-policy/ap-flowcharts.html
• Scriptlet Ordering at https://docs.pagure.org/packaging-guidelines/Packaging%3AScriptlets.html

Example output: https://github.com/NLnetLabs/dnst/actions/runs/11833713033

Note that man pages are not included properly yet because I am interested in using Ploutos to help with that.

[pemensik]

Comment about licenses. Fedora has switched to SPDX licenses only. license tag should contain SPDX expression even for RPM. afaik. We have rust2rpm tool for autogenerating rpm spec file for rust projects. Those are a way to get official package into Fedora, at least. But requires each dependency properly packaged in distribution in compatible versions. Which blocks for example review of dnsi tool.

[ximon18]

Hi @pemensik,

For our Rust projects we provide packages using our packages.nlnetlabs.nl repository built using our Ploutos tool.

We do not at present plan to provide packages in the form required by particular distributions.

If others wish to take up packaging of our tools for inclusion in official distribution repositories we of course welcome such efforts.

Ximon

[pemensik]

There is no need for you to prepare any packages. It is just important that package contain all required files for packagers, like me, to prepare a package. And eventually maintain it in official distribution repository.

That is not in conflict with your prepared packages.

[ximon18]

If we can adjust the fields to be compatible with external needs while not breaking our existing processes we will be happy to do so.

[ximon18]

By the way, https://github.com/NLnetLabs/routinator Cargo.toml has the same license field as this project (it was copied from there) so presumably that project is also incompatible with rust2rpm? I ask because https://rhel.pkgs.org/9/epel-x86_64/routinator-0.14.0-3.el9.x86_64.rpm.html exists.

[ximon18]

There's even https://packages.fedoraproject.org/pkgs/rust-routinator/routinator/.

[ximon18]

But requires each dependency properly packaged in distribution in compatible versions. Which blocks for example review of dnsi tool.

If I understand correctly you are saying that each Rust dependency needs its own package in Fedora. I have no opinion about that approach to packaging and appreciate that distribution maintainers have their reasons for choosing this approach.

What it is not clear to me (and my apologies, I have not read up on the Fedora Rust packaging requirements) is whether something is expected from us to get those dependencies packaged.

Also, did you mean to say dns_i which is a different project than dns_t? (the names are not very different so it could be a typo)

[pemensik]

If you are interested, here are Rust guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/
No, I am aware dnsi differs from dnst.

dnst has much lighter dependencies, in fact since we have rust-domain in Fedora already, it might become normal package if review is done.

You can check dnsi dependencies at my copr: https://copr.fedorainfracloud.org/coprs/pemensik/rust/

Yes, preparing truly shared packages is not a small task, especially when some package conflicts with other dependencies sometime.

[ximon18]

So, looking further down Cargo.toml we do set the license to a Fedora compatible BSD value for use by cargo-generate-rpm.

Looking at https://doc.rust-lang.org/cargo/reference/manifest.html#the-license-and-license-file-fields it requires an SPDX license name, and given that we successfully publish Routinator to crates.io with the same license field value that dnst has in this PR, I'm confused as to what the problem is that you are asking us to fix?

[ximon18]

Another thought on this: if the current license field value is valid per Cargo manifest format and crates.io rules, changing it to match one external tool such as rust2rpm doesn't seem right as it might then become incompatible with some theoretical rust2deb tool that has different requirements.

Perhaps rust2rpm should look first for a package.metadata.rust2rpm.license field instead?

[pemensik]

Here, line 53 of Cargo.toml, contains BSD. That is not SPDX license. recent rpmlint should not complain about BSD-3-Clause anymore. It should complain about BSD now. Just remove extra license for rpm?

[ximon18]

We can look at changing that, but why would a field in an external tool specific table cause a problem for rust2rpm, it should ignore this field?

Also, we build packages for multiple versions of different distros and the rpmlint version used is the one present in that distro version, it's not a fixed or latest rpmlint version. So changing this to a value compatible with recent Fedora might make it incompatible with older CentOS or such. We can work around that using per variant configs I think if needed. We probably haven't hit this issue that you describe because we haven't yet had time to update Ploutos to test against newer O/S versions.

[pemensik]

NLnetLabs/routinator#979

[pemensik]

That has changed and is now invalid. SPDX should be there as well. Use recent enough rpmlint. https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_field