Stuart Henderson <[email protected]> wrote: > > I don't think we'll be able to make it default, Theo will object. > > If you want it, you have to convince *him*, not me.
I've encountered a few situations with _mostly offline machines_ where the rsync package is need, and thus, 1 file can be copied over for pkg_add. I don't think I'm the only person to encounter this situation. My objection was that rsync suddenly needed a pile of dependencies, and it would take multiple steps to satisfy them all. A simple procedure becomes onerous. > > The problem is not onerousness, but rather Theo being scared of more > > compression algorithms, which tend to be rife with overflows... No, my concern was about the flood of hard to discern dependencies, and a semi-common installation workaround. > Oh, I guess the commit message was wrong then > > "Disable lz4, zstd and xxhash again > The dependencies are too big" > > lz4 has a reasonably good track record (not spotless but not rife > with overflows) and (unlike rsync's internal zlib, which is 1.2.8 plus > some rsync patch) is now extensively fuzzed > https://github.com/lz4/lz4/releases Maybe capabilities those make sense. It would be even better if they were not dependencies, but included as internal. I don't know how common that method is. > I am far more concerned about rsync itself which is already a labyrinth > of so many options that it's nigh on impossible to get wide test > coverage, but *shrug* there's no usable alternative for what it does, > I jail it, what more can I do? BTW, it would be great if openrsync could be used in such situations instead. The first 90% of the work is done in it, but the next 10% towards making it fully capable turns out to be another 90% task, and I guess we are waiting for a wave of developers to step in there improve those issues. openrsync would satisfy a majority of use cases. History shows us we often have bad outcomes when there is only one implementation of a tool.
