Bug#1028467: ITP: borgbackup2 -- version 2.x of a deduplicating and compressing backup program
Control: tags 1029085 + wontfix
Control: close 1029085
Hi Scott,
On Tue, Jan 17, 2023 at 02:52:49PM +0000, Scott Kitterman wrote:
> It's not policy compliant, which may be okay in this instance, but it certainly isn't ideal.
I looked into this and figured that indeed the Debian Policy has a
section 6 on this matter. Interestingly, this policy says little about
how compatible programs actaully need to be. It merely states that
packages need to cooperate. It also mentions vim vs nvi as an example.
If you've ever used either and then gotten onto a system that selected
the other or even just vim-tiny, you notice significant differences in
their usage and abilities. To me, the differences between borg 1.x and
borg 2.x are similar, so I consider the vi example a supporting argument
for using alternatives.
I happen to had to look into whether update-alternatives are appropriate
as part of the CTTE decision on the rename implementation. There, the
CTTE ruled that they should not use update-alternatives, because you
couldn't actually use them in a compatible way. This does not apply to
the borg transition where a number of invocations continue to work.
> Here's another approach:
Let me call this the python approach, because python pioneered it with
python-is-python2 and python-is-python3. From a user point of view, this
practically is an implementation detail with three differences to
update-alternatives:
* You may choose not to have the unversioned instance (by not
installing a *-is-* package).
* You can depend on the unversioned instance being a particular version
using a package dependency.
* The incantation for changing the unversioned instance is a different
command.
Other than this, little changes from a user's point of view. So is any
of these differences relevant here?
I think lacking an unversioned instance is not an important feature. The
difference in incantation is not something I care about either. However,
being able to depend on a particular version is something I didn't
really consider in sufficient depth thus far. Indeed, borg does have
reverse dependencies:
* backupninja
* borgmatic
* fbx-all
* freedombox
* vorta
* And maybe some ITPs for other frontends as well.
Moving forward with my update-alternatives plan could mean breaking any
of these. For instance,
* backupninja uses borg init
https://sources.debian.org/src/backupninja/1.2.1-1/handlers/borg.in/#L129
* borgmatic adapts to the borg version dynamically and can handle
either
* fbx-all is a metapackage and happens to Recommend borgbackup among
other things
* freedombox uses borg init
https://sources.debian.org/src/freedombox/23.2/plinth/modules/backups/privileged.py/?hl=183#L119
* vorta uses borg init
https://sources.debian.org/src/vorta/0.8.9-1/src/vorta/borg/init.py/#L31
My update-alternatives approach would break three of them, so that's a
big argument against using update-alternatives.
The python approach has a different downside.
> Borg 1 gets a new binary, borg-is-borg1 that provides usr/bin/borg symlinked to borg1. The existing package depends on it for Bookworm, so it's guaranteed to be installed.
If borg depends on borg-is-borg1, then of course you cannot coinstall
borg 1.x with borg-is-borg2. I'm not sure whether this is relevant. In
any case, we can simplify the matter here by making borgbackup Provides:
borg-is-borg1 and do away with one package. We can actually do away with
the whole borg -> borg1 rename dance as you can never have borg1
installed without borg being borg1. So, we can just skip this entirely.
That laves borgbackup2 shipping borg2 and borg-is-borg2 shipping
symlinks and Conflicts: borgbackup. The benefit here is that installing
borg-is-borg2 will kick all of the reverse dependencies. borgmatic
should update its own to borg-is-borg2 | borgbackup.
So thank you for your persistence on this. The fact that
update-alternatives do break rdeps is a really convincing argument, that
only came across relatively implicitly.
Helmut
Reply to: