Your message dated Fri, 20 Jan 2023 12:56:36 +0100
with message-id <y8qbdocri8bva...@alf.mars>
and subject line borgbackup2 uploaded to experimental
has caused the Debian Bug report #1028467,
regarding ITP: borgbackup2 -- version 2.x of a deduplicating and compressing
backup program
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1028467: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028467
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
The first upload was rejected and I failed to send the whole changes,
thus closing manually.
Helmut
--- End Message ---
