Hi again Laszlo,
I thought I would revisit the conversation in 918075. Since then,
I think we have had additional features in 2.7.x. At the moment,
I believe this is a list of things we could support in dar on
Debian but aren't:
zstd compression
lz4 compression
multithreading
delta compression (librsync)
remote repository (libcurl)
argon2 hashing (libargon)
Python library
Necessary libraries for all of these except multithreading are in
Debian already.
If I might summarize the situation:
- There is concern that some of these libraries are not available
in static versions in Debian, and thus dar_static can't be built
with them.
- On the other hand, we are now at a point where Debian's dar is
incapable of extracting quite a few archives made by dar on
other platforms (or locally-compiled dar). dar_static is of
little use if it can't unpack the archive anyhow. zstd and
delta compression, in particular, are two quite compelling
features that we are lacking.
I propose:
1) Packaging up threadar
2) Pick one of:
2a) Enabling all libraries in the dynamic version, and as many as
possible in the static version, and document the situation;
2b) Take an approach like exim4-daemon-heavy vs.
exim4-daemon-light, and provide a dar-light and a dar-heavy binary
package, which differ in what libraries are linked in.
2c) Enable all libraries in the dynamic version, and drop
dar-static entirely.
I volunteer to do the work. I would be happy to package up and
maintain threadar, and to send you patches for dar, be a
co-maintainer for dar, or take over maintaining dar, whatever you
may prefer.
As for which option 2 we choose, my preference is 2c, followed by
2a. I think that a light vs. heavy package is overkill in this
situation (exim did this because the "heavy" package really did
bring in significant heavy libraries like SQL and such).
Comparing with other similar packages on the system:
- GNU tar, at /bin/tar, is dynamically linked but calls external
archivers as a separate process and therefore doesn't link them
in.
- bsdtar, at /usr/bin/bsdtar, is dynamically linked and has a very
similar set of libraries it would use compared to dar. bsdtar's
own libarchive is linked in, as well as liblz4, libzstd, libbz2,
liblzma, libacl, etc. bsdtar is a multi-archive program,
supporting multiple flavors of tar, pax, cpio, shar, iso9660,
zip, ar, mtree, 7z, cab, lha, rar, warc, and xar, so it is quite
capable of creating formats that can't be extraced by standard
Debian base system tools.
- fsarchiver has its own format, and its linking approach is like
bsdtar. dynamically-linked only, links libbz2, liblzo2, liblz4,
libzstd, liblzma, libgcrypt, etc.
- p7zip uses a linking approach similar to GNU tar, dynamic only
- unrar is dynamic only
- cpio is dynamic only
- afio is dynamic only
- borgbackup is Python-only and also depends on libzstd1
- rdiff-backup is Python-only and also depends on librsync2
- duplicity is Python-only and also depends on librsync2
So what I'm trying to say here is that I can't find any other
backup/archiving tool on Debian that limits itself to what is
possible in a static binary, or even ships a static binary in the
first place. Given the existence of Debian Live images, it should
be easy enough for someone wanting to be able to extract a dar
archive to make that happen even with a completely wiped system.
All of these other tools make that assumption as well.
Ultimately, I don't want Debian's dar to be unable to unpack dar
archives because we are restricting the feature set so tightly to
what we can put in dar-static.
Thanks,
John
