Best practice for updating /etc files in-place while respecting changes?

(Tyler Langlois) #1

I’ve got a couple of formulae (for metricbeat, filebeat, etc.) that drop configuration files into /etc. When a package gets upgraded and one of the configuration files changes, the current behavior seems to be to drop a .default file alongside existing configuration files to avoid clobbering any potential user changes to those configuration files.

This works in most cases, but there can be instances in which an upgraded package expects new values in the configuration file or upstream has otherwise changed configuration defaults that should be incorporated into default config files. While the current behavior works pretty well for users who actively change their configs, users who rely on the default setup and behavior won’t get updates to config files without manual intervention.

I realize this is a somewhat long-standing package management concern in general (I remember using etc-update in Gentoo :penguin:) but I’d like to know, from the Homebrew upstream perspective, which is the most correct way to address this.

  • Should a simple caveat be included indicating that users need to check for updates by looking for .default files in their etc/ directories?
  • Should I write a little custom check that implements some logic to see whether the file has been modified and if not, just move the file in, or if so, use the traditional etc.install to avoid overwrites?
  • Should I just mv the file in altogether? It may clobber changes, but maybe I can make a backup file first?

These are just rough ideas - I’m not really sure what mechanisms are available to me, but I’d like to hear what the least problematic, forward-compatible method would be.

(Mike McQuaid) #2

This seems like the best bet for now :+1:. I considered in the past something where we’d automatically update the config if it hadn’t changed from the defaults but gave up. We’d consider accepting a PR for that.