--- Begin Message ---
Package: wnpp
Severity: wishlist
Owner: Helmut Grohne <helmut@subdivi.de>
X-Debbugs-Cc: debian-devel@lists.debian.org, team+borg@tracker.debian.org, Gianfranco Costamagna <locutusofborg@debian.org>, Danny Edel <debian@danny-edel.de>
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
--- End Message ---