[Dnsmasq-discuss] systemd service improvements

Kurt H Maier khm at sciops.net
Tue Jul 5 21:54:33 BST 2016

On Tue, Jul 05, 2016 at 04:28:14PM -0400, Craig Andrews wrote:
> On 30.06.2016 17:39, Kurt H Maier wrote:
> The "make" invocation. Just like how there is a "-DHAVE_DNSSEC" option, 
> there could be a "-DHAVE_SYSTEMD" one.

What is the advantage to putting this in the makefile itself?  None of
the distributions you mentioned ship dnsmasq source directly; they ship
packages.  The packagers all have build scripts.  The build scripts put
the files into place.  Why does this need to be offloaded onto dnsmasq?

> The point isn't (necessarily) to conserve lines of code - the point is 
> to have one place for distributions/users to collaborate in order to 
> best develop and maintain this portion of the project. And each distro 
> does not (and absolutely should not) rewrite the unit file. (Would you 
> be happy if each distro patched dnsmasq? Same thing.)

Each distro *does* patch dnsmasq.  Why does modifying dnsmasq's Makefile
make it easier for all these hypothetical people to contribute than
having the unit file in /contrib?

> Right now, note how each of these distribution's systemd units are 
> different:
> Gentoo: 
> https://github.com/gentoo/gentoo/blob/cae8d8ccd7658253a336a7595796f8a9264332de/net-dns/dnsmasq/files/dnsmasq.service-r1
> Debian: 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=debian/systemd.service;h=40b8d27cba21400d8b56ecc4a85266879988911d;hb=HEAD
> Fedora: 
> http://pkgs.fedoraproject.org/cgit/rpms/dnsmasq.git/tree/dnsmasq.service
> The differences are in paths (a Makefile can eliminate those difference) 
> and different security features (which are only different because some 
> distros didn't notice some security features).

Are you suggesting dnsmasq override distribution file heirarchies?  And
why do you assume packagers "didn't notice" some of the security
features?  Is it impossible they decided not to enable them for specific

> Distros are trying to use upstream units and get upstreams to include 
> units:
> * Fedora: https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files 
> "Ideally, systemd unit files are reusable across distributions and 
> shipped with the upstream packages. Please consider working with 
> upstream to integrate the systemd files you prepare in the upstream 
> sources."
> * https://wiki.archlinux.org/index.php/DeveloperWiki:Systemd#Units "Use 
> the upstream unit files whenever they exist"

Fedora wants this because Red Hat pays the systemd maintainers, so any
time they can get other projects to do their work for them, they save
money.  Arch wants this because they're undermanned and their packagers
need all the help they can get.  I don't think either of these
conditions are universal.

> A growing number of projects (big and small) have upstreamed systemd 
> units, such as:

I'm not sure "me, too" is a very good reason to make this change.  I
would instead start by convincing the distros you mention above to use
the unit file dnsmasq already has in /contrib, and getting them all on
the same page.  dnsmasq is a very flexible tool whose deployment needs
to be crafted to the situation in which it is used.  Aside from some
tuning tweaks, most of the applications you list are classical 
monoliths, where dnsmasq is very commonly used as part of a larger
package of tools. 

In short, the only people who would save time on this are packagers, and
the only time it would really save them is not having to add a "copy
unit file" line in their build scripts.  

For example, I frequently build dnsmasq for deployment to networking
devices of all shapes and sizes; a coworker most frequently builds
dnsmasq as part of openstack or docker+kubernetes development.  In each
of those cases, we're building on a systemd-equipped machine, but we're
not installing dnsmasq as a systemwide service suitable for activation
by systemd.  I'd argue that you may find such deployments of dnsmasq are
far, far more common than you'd think.

I support your plan to get all the distro packagers on the same page,
and standardize the unit file for everyone.  I just really don't think
the dnsmasq build system is the place to do it.


More information about the Dnsmasq-discuss mailing list