[bug#33026] [PATCH] gnu: Add pdns.

[Tobias Geerinckx-Rice]

Ludo',

Ludovic Courtès wrote:
> What about “powerdns” then?

This patch originally added 'powerdns' (my preference), then I 
changed it :-)
pdns is the far more common name in GNU/Linux land. The BSDs tend 
to go with powerdns.

- pdns:	 Alpine, Debian, Fedora, Gentoo, brew, openSUSE, Slackware 
 :-), and derivatives
- power: Arch, *BSD, Nix :-), and derivatives

The upstream tarball also uses the pdns- prefix.

So I'm all for using 'power' but expected some astonishment during 
the review. POLA and all that.

> Why not keep all the commands in the same output?  Is it to 
> avoiding
> cluttering user profiles, or is it a matter of package size?

The former. Building them is not the upstream default, and I 
personally don't like them littering my profile (this is entirely 
subjective).

On the other hand I don't think users should have to go so far as 
to customise the package to get to the tools, so this was the 
compromise.

I don't think either is ideal.

> > +Domain Name System (@dfn{DNS}) that supports a wide variety of 
> > storage methods.
>
> I think you can avoid @dfn here as well.  :-)

OK. I'll also remove it from my (already reviewed) NSD package for 
consistency.

> A few questions:
>
>   • Are things under ext/ simply bundled libraries?  If so, do 
>   you think
>     there’s something we could/should do about them?

I'll take a closer look.

>   • I suppose we don’t build and thus don’t care about the 
>   license of
>     modules/oraclebackend, do we?  :-)

Hm, is that how this works? Or is Oracle's DB non-free? I know 
nothing about Oracle, which might itself be the anwser to that 
question.

If it is, shouldn't we remove the whole thing in a snippet unless 
the build system really hates that?

>   • The license of m4/* doesn’t matter for the combined work; 
>   I’d just
>     remove it.

OK. I'll never fully grasp these legal combinatorics.

>   • GPLv2-only code cannot be combined with GPLv3+ code.  Is it 
>   really
>     what’s happening?

Let's hope and assume not, then. Closer look.

Thanks!

T G-R