Hi Simon, Le samedi 19 juillet 2014 à 22:01 +0100, Simon Kelley a écrit : > It would be fairly simple to support this upstream, and with hindsight > it's a better way to do things. My main concern is that to make the > change now introduces a behavior change with the potential to break > existing installations.
Yes, I understand. > There may be a way around this, since the directive which tells dnsmasq > to load the contents of /etc/dnsmasq.d is in /etc/default/dnsmasq > > # By default search this drop directory for configuration options. > # Libvirt leaves a file here to make the system dnsmasq play nice. > # Comment out this line if you don't want this. The dpkg-* are file > # endings which cause dnsmasq to skip that file. This avoids pulling > # in backups made by dpkg. > CONFIG_DIR=/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new > > Since /etc/default/dnsmasq is a conffile, that could be left alone for > existing installations which are upgrading, but new semantics introduced > for new installations, ie delete the line above and add > > CONFIG_DIR_FILE=etc/dnsmasq.d,.conf > > with suitable scripting in the init script and an extension of the > --conf-dir dnsmasq flag. > > > Opinions? Well, frankly, making this configurable seems overkill to me. On my current setup, I see no other software having a configurable configuration dir in /etc/default. Better behave the standard way by default (hardcode /etc/dnsmasq.d in the init script), without setting any CONFIG_DIR* in /etc/default/dnsmasq. This way, the libvirt trick is still taken into account; we *may* need a way to disable it, but it seems so badly needed that I won't cry if it's not possible to do without manual tweaking. Then we have no more dpkg-* exceptions, as only "*.conf" are included. That with a warning on the next upgrade (it seems I already saw such warning elsewhere for this kind of transition some times ago; same thing, to only choose *.conf and not others), so as not to break too much. It's only a renaming issue, if correctly advertised. The most ugly part (to me) would be to extend the --config-dir flag in a not-too-ugly way, which I can't think of right now. Thanks for investigating this! (and I didn't know you where the maintainer too: thanks for all this work) -- Benjamin Cama <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
