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 <helmut@subdivi.de> wrote:
>Hi Jonathan,
>
>Thanks for your review.
>
>On Tue, Jan 17, 2023 at 02:12:10PM +0000, 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
Reply to: