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 +, 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
Bug#1028467: ITP: borgbackup2 -- version 2.x of a deduplicating and compressing backup program
On January 17, 2023 2:39:32 PM UTC, Helmut Grohne wrote: >Hi Jonathan, > >Thanks for your review. > >On Tue, Jan 17, 2023 at 02:12:10PM +, Jonathan Dowland wrote: >> I'm not sure that alternatives is appropriate, if the commands are not >> interchangeable. And they are not: if you have 1 & 2 installed on a >> host, and have used one to create some backups, trying to use the other >> could be disastrous, and mixing them up a very real possibility if >> either could concretely own "borg". IMHO, borg1 got that name and should >> keep it, and borg2 should exclusively use a different command name, even >> though that makes us significantly divergent from upstream. > >I agree that alternatives are not 100% appropriate for this situation, >but I think that it is a good trade-off. > >The chances or destroying your backups are fairly minimal. Practically, >things will mostly stop working due to unknown options and commands. > >I think that before too long, people want to get rid of borg 1.x and >forget about it. Keeping the 2 suffix is just making it painful down the >road. As such, I want a way that allows us to drop it eventually. > >>From my point of view, there are three relevant scenarios: > >1. A borg server. Such a system wants both borg 1.x and borg 2.x > available to allow users to transitions their repositories when > they're ready. Users should be advised to set BORG_REMOTE_PATH to > something other than "borg" in this case. > >2. New users installing borg 2.x for the first time. We really want them > not to experience the transition cost. They should be able to use > borg as if there never was borg 1.x. > >3. Users upgrading from borg 1.x. Here, we want to decouple the borg > upgrade from the dist-upgrade. To do this, users will have to install > borg 2.x (not necessarily concurrently), transfer their repositories > and adapt a few command lines. > >Only in scenario 1 where the suffix is unavoidable and also being used >by major borg providers such as rsync.net, borgbase or hetzner, we don't >want to deal with suffixes. > >And with that I arrive at update-alternatives being the best available >compromise. Do more people disagree with this plan? It's not policy compliant, which may be okay in this instance, but it certainly isn't ideal. Here's another approach: 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. The new borg2 package has a borg-is-borg2 binary which provides usr/bin/borg pointing to borg2. These two packages conflict, so that only one usr/bin/borg provider can be installed. After Bookworm is released, borg1/borg2 can recommend their usr/bin/borg provider and the user can pick. Once borg1 is removed, the extra packages can be dropped too. This might be a little more work and needs a trip through new, but I think it's policy compliant and a little lower risk. Scott K
Bug#1028467: ITP: borgbackup2 -- version 2.x of a deduplicating and compressing backup program
Hi Jonathan, Thanks for your review. On Tue, Jan 17, 2023 at 02:12:10PM +, Jonathan Dowland wrote: > I'm not sure that alternatives is appropriate, if the commands are not > interchangeable. And they are not: if you have 1 & 2 installed on a > host, and have used one to create some backups, trying to use the other > could be disastrous, and mixing them up a very real possibility if > either could concretely own "borg". IMHO, borg1 got that name and should > keep it, and borg2 should exclusively use a different command name, even > though that makes us significantly divergent from upstream. I agree that alternatives are not 100% appropriate for this situation, but I think that it is a good trade-off. The chances or destroying your backups are fairly minimal. Practically, things will mostly stop working due to unknown options and commands. I think that before too long, people want to get rid of borg 1.x and forget about it. Keeping the 2 suffix is just making it painful down the road. As such, I want a way that allows us to drop it eventually. >From my point of view, there are three relevant scenarios: 1. A borg server. Such a system wants both borg 1.x and borg 2.x available to allow users to transitions their repositories when they're ready. Users should be advised to set BORG_REMOTE_PATH to something other than "borg" in this case. 2. New users installing borg 2.x for the first time. We really want them not to experience the transition cost. They should be able to use borg as if there never was borg 1.x. 3. Users upgrading from borg 1.x. Here, we want to decouple the borg upgrade from the dist-upgrade. To do this, users will have to install borg 2.x (not necessarily concurrently), transfer their repositories and adapt a few command lines. Only in scenario 1 where the suffix is unavoidable and also being used by major borg providers such as rsync.net, borgbase or hetzner, we don't want to deal with suffixes. And with that I arrive at update-alternatives being the best available compromise. Do more people disagree with this plan? Helmut
Bug#1028467: ITP: borgbackup2 -- version 2.x of a deduplicating and compressing backup program
Package: wnpp Severity: wishlist Owner: Helmut Grohne X-Debbugs-Cc: debian-de...@lists.debian.org, team+b...@tracker.debian.org, Gianfranco Costamagna , Danny Edel The root of this ITP is #1019950. The crux of the matter is that borg 2.x is not very compatible with borg 1.x. I talked to upstream and as far as I understand things, the compatibility is quite limited: borg 2.x expects to deal with borg 2.x serve or a borg 2.x data store. Additionally, borg 2.x can read from a borg 1.x serve and borg 1.x data stores. As part of the upgrade process, users have to convert their borg 1.x data into the borg 2.x format. This involves copying the entire repository. If we were to just update the borgbackup package to ship version 2.x, a number of bad things could happen: * Users trying to back up after a dist-upgrade will no longer be able to write to their repositories until they have upgraded them, i.e. backups will just stop working. * When upgrading a borg server machine, all clients running borg 1.x will no longer be able to back up until they upgrade their borg installation and upgrade their repositories. As such, I want to make borg 1.x and borg 2.x coinstallable. This eliminates much of the trouble: * During a dist-upgrade, people will continue using borg 1.x and backups will continue to work. * borg server machines can coinstall borg 1.x and borg 2.x and thus serve borg 1.x clients and borg 2.x clients at the same time. * Users can install borgbackup2 and migrate their backups. Once finished, they can remove version 1.x and hope that the next upgrade becomes simpler. * The idea is that borgbackup gains a "borg1" command and borgbackup2 is shipped as "borg2". The original name "borg" shall be managed using update-alternatives with "borg1" taking a preference in bookworm and changing that in trixie. * Release notes shall warn users about this change I hope this makes sense Helmut
