Package: wnpp Severity: wishlist Owner: Helmut Grohne <hel...@subdivi.de> X-Debbugs-Cc: debian-de...@lists.debian.org, team+b...@tracker.debian.org, Gianfranco Costamagna <locutusofb...@debian.org>, Danny Edel <deb...@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
