Allow "overwriting" of entries

[thkukuk]

If you have a system which is using image based instalation and update (e.g. image = /usr, not full disk images, like e.g. CoreOS) or if you use a system with atomic updates, it is not possible to install or update configuration files in /etc in a safe and transparent way.

The goal here on such distritubions is, to have only host specific config files or admin changes in /etc and everything else in a vendor specific directory below /usr as fallback. Best example for software doing this way is systemd, where the vendor default is in /usr/lib/systemd and the admin changes in /etc/systemd.
While systemd is one solution, there are others like openssh is doing, where you can specify several include locations and the first or last entry wins.

logroate has by default everything in /etc, which creates a problem for such systems. It's easy to move that to another location below /usr, but then it's not easy anymore for an admin to adjust the distributor shipped config or overwrite them.

Best would be if logrotate would handle this config files the same way as systemd does, but since this would be most likely incompatible to the current behavior, it would be already good enough if it only uses the first (or last definition) like openssh and does not throw an error if multiple definitions are found.

I see the following options:

• rewrite configuration file handling like systemd is doing (most likely incompatible)
• if a file is found in multiple include statements, only use the first/last one (don't know if possible with current design)
• only use the first statement if it occurs multiple times (most likely the easiest solution)

Depend on the preferred solution I could help to implement that.

More background informations:
https://github.com/thkukuk/atomic-updates_and_etc

[kdudka]

I believe that overriding of global options is more or less already implemented. Overriding of log-specific configurations could be implemented unless we hit some some design limitations, like we did with #38. Extending the include directive to allow fallback locations could also be an option.