On Thu, Nov 18, 2021 at 5:27 PM John Goerzen <jgoer...@complete.org> wrote: > 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: [...] > 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. Yup. I think dar-static has its place. If it can't provide the same functionality like the dynamically linked version then there will be a confusion why it doesn't work.
> - 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 think we should check how other distributions compile dar and follow those at least in support. > I propose: > > 1) Packaging up threadar Thanks, other projects might benefit from that. > 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; From my point of view, this would be the best choice. > 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. I think if someone uses a 'normal' system then s/he has enough space to install dar with all possible compiled in and the dependencies needed for that. > 2c) Enable all libraries in the dynamic version, and drop > dar-static entirely. I think dar-static should be left in. Someone might archive a system for limited architectures like armel or riscv64. Then s/he can boot a minimal system (CD or pen drive), drop dar-static in it and restore the system or just clone that easily. > 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. I prefer if you send patches to dar upstream and those are integrated into the next release. Also dar is a small enough package, only one maintainer is enough. If you volunteer to take over it then I'm open to give it to you. > 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. Hmmm. Does Live images contain every dependency that a full functionality dar would have? Ie, can dar package fit into these easily? > 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. Sure, if the difference between dar-static and dar is documented (ie, what support the former can handle), then the latter can be a fully functional package. Cheers, Laszlo/GCS
