Hi Antoine and team/collective, Antoine Beaupré <[email protected]> writes:
> On 2025-11-18 19:14:35, Nicholas D. Steeves wrote: >> Antoine Beaupré <[email protected]> writes: >> >> I'd appreciate if you would review my WIP (which I finally pushed). In >> particular, I'd appreciate your perspective on that potential UX >> enhancement and am wondering if there's a better way to do it and to >> support upstream's efforts to make config migration less painful. The >> obvious downside to upstream's current implementation is that it erases >> comments in the config. > > Hmm... I'm not sure. First, I think this should be gated on a `[ -d > /etc/borgmatic ]` otherwise it could crash the postinst on an > unconfigured system: > > for i in /etc/borgmatic/*.yaml; do > > Did you actually this in a clean install? I had not gotten there yet, because this was a POC focused on existing users. Yes, you're of course right and I've fixed the WIP. > I'm not sure we should be doing this for our users though... It seems a > little daring! But why not... The problem as I see it is upstream keeps breaking existing user configs (see https://bugs.debian.org/1099802), and backups that aren't painless and automatic have a tendency to not be updated... That said, does rewriting, updating, and implicitly checking/validating a config on upgrade violate the principle of least surprise more than this: a) 1. Provide a rewritten & valid $n.dpkg-dist for each config file on each upgrade. 2. In Debian.NEWS, when there are breaking changes, point the user to this file. -- hopefully errors with obsolete and invalid config when users ignore D.NEWS...and users are provided with a template generated by their site-specific config vs b) (My WIP POC) 1. Back up each config file to $n.dpkg-old and rewrite /e/borgmatic/$n 2. In Debian.NEWS, when there are breaking changes, remind the user. that dpkg-old exists in case the auto-migrated config missed something. -- hopefully doesn't miss source data due to dropped obsolete and invalid config when users ignore D.NEWS. c) 1. Back up each config file to $n.dpkg-old and rewrite /e/borgmatic/$n, and stop bothering use with Debian.NEWS (this assumes that upstream migration tool isn't buggy) 2. Stop bothering the user and interrupting upgrades -- hopefully doesn't miss source data due to dropped obsolete and invalid config; assumes users tend to ignore D.NEWS. d) 1. Continue shipping D.NEWS, when needed, and do nothing more -- NEWS interrupts upgrade, but users will ignore NEWS, users have broken config (hopefully errors...) What do you think is the least bad option? I initially chose "b" because I was optimistic and chose to have faith in upstream and their migration tool. Regards, Nicholas
signature.asc
Description: PGP signature
