borg2: hints for maintainers

[ThomasWaldmann]

Some hints for Linux / BSD / other OS package maintainers:

libs

additionally to openssl, libacl, libattr, lz4 and zstd, we now also need:

• libxxhash

some of that code was bundled into previous borg versions, but we just unbundled it for the future (so it won't work any more for borg >= 2.0 if you do not have a working library).

make sure ALL libs have a LIBNAME.pc file for pkg-config because we use that for discovery.

the requirements are documented in our docs / in setup.py.

#6593 removes support for libressl, borg requires openssl >= 1.1.1 now.

python packages

we'll additionally need:

• argon2-cffi

python 3.9

we'll require that as a minimum for borg >= 2.0.

dist specific hints

freebsd13: no .pc file for openssl
freebsd13: fuse issue #6871
openindiana: #6797

[ThomasWaldmann]

https://github.com/borgbackup/borg/pull/6459/files < i used some workarounds there to make some stuff working.

The BORG_LIB......_PREFIX stuff is only needed if there is no working .pc file.

[ThomasWaldmann]

Note: I'll clean up a bit in the posts above removing all references to libdeflate (which was removed again by #6834 as borg2 will make much less use of crc32 than borg1 did, so it isn't worth it to have libdeflate as an addtl. requirement).

[pgerber]

I wonder there should be some recommendations about packing Borg 1 and Borg 2 separately. Migrating from one to the other will take some time for many people as server need to be updated first (while Borg 1 is still in active use) and then all the clients. For clients the situation gets a bit more involved should they push to multiple repositories where one may not want to update both servers at once. All in all, having both, Borg 1 and Borg 2, available at the same time would be very helpful to users.

So, perhaps there should be a borg1 and borg2 package with separate binaries. A borg metapackage that depends on one of them could be added too and, something like update-alternatives (on Debian) could be provided to have /usr/bin/borg symlinked to borg1 or borg2.

[ThomasWaldmann]

Guess the best idea yet was:

• do not put the python code into the global python site-packages, but have them in a private space of borg1 and borg 2. the python code is not used by anything else besides borg, so there is no good reason to have this there and it also avoids the conflicts because the package directory of both borg versions is named borg.
• have borg1 and borg2 cli commands (or even borg1.x and borg2.x) and use a symlink or some dist-specific mechanism to have one of them also as borg cli command

[ThomasWaldmann]

As #7300 is merged now (and is in 2.0.0b5), borg will require platformdirs >=3.0.0, <4.0.0.

This is because it needs 3.0.0 to get the macOS directories right. For Linux, a relatively recent platformdirs 2.x.x would also work.

The <4.0.0 is a precaution to not suddenly/unexpectedly get borg broken in case platformdirs has a future breaking release.

See also: https://github.com/borgbackup/borg/pull/7396/files

[ThomasWaldmann]

#8332 brought some big changes, including that borg now requires the borgstore python package.

Since borgstore 0.0.4, it has a rclone backend that requires rclone >= 1.57.0 (binary) and requests >= 2.25.1 (python package).

[ThomasWaldmann]

borgstore offers an sftp backend based on paramiko. paramiko depends on "cryptography" package which has rust as a build dependency.

i noticed that this can make troubles on some platforms and made the sftp backend optional:

• if paramiko is installed, sftp is available.
• if it is not installed, then the sftp backend won't be available
• all the other backends will work in any case (currently we have the posixfs and rclone backends)

[ThomasWaldmann]

New since 2.0.0b13: borg2 now depends on borghash project (a new hashtable implementation in pure Cython).