> Yep, I did that already (did you see the updated service file?). Not when I wrote my last message, but I have now. It's much better, thank you. > >>> 1) Make dnsmasq capable of getting the DNS domain name on its own. It’s not >>> too >>> much code, I’ve ripped out the appropriate parts of 'hostname', it’s less >>> than one page of code, see http://p.nnev.de/2017. Not sure if it becomes >>> even less code when using functions which are in your code-base already. >>> >>> Advantages: You could make that lookup asynchronuous, thus starting >>> dnsmasq >>> faster (it does not have to wait blockingly on resolving the hostname but >>> can immediately show up on DBus). Also, we don’t have to use shell in the >>> boot process just for expanding the parameter. >>> >>> 2) Start /bin/sh -c 'dnsmasq …' in the service file. >>> >>> Advantages: No code changes to dnsmasq. >>> >>> I do prefer the first option. What do you think? >>> >> I think this approaches the problem from the wrong end. Consider this >> scenario: user installs dnsmasq and configures it by editing >> /etc/dnsmasq.conf, /etc/default/dnsmasq, dropping files in >> /etc/dnsmasq.d. Now user installs systemd and expects dnsmasq to be >> started by systemd instead of the sysV initscript. The systemd-started >> dnsmasq should behave in the same way as before and not arbitrarily >> ignore some of the configuration which previously worked. The >> dnsdomainname line (and the others) have been in /etc/default/dnsmasq >> for a long time, backwards compatibility says it should continue to work >> and if it doesn't, the package maintainer (ie, me) will rightly get grief. > Well, if we go for option 1, we could deprecate the DOMAIN_SUFFIX variable and > have a way that works for sysvinit *and* systemd. > > Apart from that, I don’t really see a way to still support the DOMAIN_SUFFIX > variable without shipping a Debian-specific script that generates a temporary > config file. I consider that really ugly, though, for multiple reasons: It’s a > shell-script and in the systemd world we like to avoid those. Furthermore, > it’s > Debian-specific, so other distributions still have the problem of setting the > domain suffix. I’ve asked in #systemd and Fedora uses a service file where the > user has to manually configure the domain suffix in /etc/sysconfig/dnsmasq. On > Arch Linux, the user is supposed to configure it in /etc/dnsmasq.conf.
I would be inclined to just state that the whole of /etc/default/dnsmasq is not used when systemd is in use except that we haven't yet addressed resolvconf. It seems to me that the wrapper script is the only way to solve that problem, too, so maybe it's worth biting the bullet and doing it. Yes, it's a bit nasty, but it makes it very easy to retain complete backwards compatibility in the Debian package. That really is valuable - it's one of Debian's USPs that upgrades Just Work. I'm happy to distribute a service file without the Debian elaborations too, in fact I already do: /contrib/systemd/dnsmasq.service v. debian/systemd.service resolvconf is an issue. Not supporting it will break far more systems than DOMAIN_SUFFIX. > > Unrelated to that issue, I’ve learnt that the handling of /etc/default/locale > to have LANG is completely unnecessary in systemd. systemd will read > /etc/locale.conf and fall back (on Debian) to /etc/default/locale anyways, so > all services have correct environment without doing anything specific. I’ve > updated the service file accordingly and attached the most recent version. That's good. I'll think about how to do a wrapper and get back to you. Cheers, Simon. > > Best regards, > Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
