Hi Andrey! Andrey Rakhmatullin <[email protected]> writes:
> Package: borgmatic
> Version: 2.0.11-1
> Severity: important
>
[snip]
> There are two things here:
>
> 1. To my knowledge, and how I do it on my machines (but which may be a
> misunderstanding), user configs go into /etc/borgmatic.d, not
> /etc/borgmatic.
There are a few things happening here:
1. I didn't account for configs in /etc/borgmatic.d/, so the fault is
mine.
2. Upstream defines /etc/borgmatic.d/{foo,bar,baz}.yaml as
"application-specific" or "container-specific" config rather than user
configs. User configs use XDG_CONFIG_HOME. `borgmatic config generate`
creates /etc/borgmatic/config.yaml as the default system-level
configuration. https://torsion.org/borgmatic/search/?query=borgmatic.d
3. If more "technically apt" Debian users and sysadmins are already
using /etc/borgmatic.d like other /etc/service-config.d/drop-in-config
then maybe we need to honour the assumption that these configs are never
autoupdated/automigrated? At least, I'm not aware of any... In other
words, would it be a better policy to do this:
a) Put /etc/borgmatic/config.yaml under dpkg control at some point.
I think it would be really nice if we had an exim4-like
dpkg-configure wizard to make setting up system-level backups using
a couple of common templates really easy. Option
"no-configuration" would of course also be an option.
b) /etc/borgmatic/config.yaml will (eventually) be rewritten on
upgrade. If upstream's migration tool is buggy, that bug is caught
in sid or testing. The point of all this is "easy backups for
everyone".
b.q1) Do we need to worry about people setting the immutable flag on
/etc/borgmatic/config.yaml and do we need to test if it's
actually writable before attempting to write to it?
c) We document that our /etc/borgmatic.d/* follows the
/etc/service-config.d/drop-in-config convention and is never
migrated in any way; this has the side-effect of addressing Simon
Pilkington's preference at #1121156 in an elegant and consistent
way. Do you think this is too much of a stretch from upstream's
design, documentation, intention, etc. balanced against our users'
expectations?
> 2. If there are no files matching /etc/borgmatic/*.yaml (like on my machine)
> the script fails with
>
> Generating a configuration file at: /etc/borgmatic/*.yaml.dpkg-dist
> [Errno 2] No such file or directory: '/etc/borgmatic/*.yaml'
>
> because the loop doesn't have zero steps, but one, with
> $i=/etc/borgmatic/*.yaml.
Hmm, the only way that I was able to reproduce this was by manually
creating an empty "/etc/borgmatic", and then not writing nor generating
any config files inside of it. I confess I didn't accommodate for this
middle state, and the maint script is starting to feel like bad style
(ie case by case instead of a robust general solution) at this point so
I'm working on one that uses `find` instead.
While I have your ear, and while we're talking about our users'
expectations, what do you think about removing
/etc/{borgmatic,borgmatic.d}/ on `apt purge`? That's the expected
behaviour, right? Also, borgmatic users have backups, right? ;)
Cheers,
Nicholas
signature.asc
Description: PGP signature
