Hard dependency on zstd, make it possible to use others

[irelativism]

Since release 3.5 the project is enforcing zstd using it as mandatory dependency. So the last functional version is 3.4.1.

Ztsd even if free and permissive licensed is quite bloated and this removal for choice left to fast select another interface and dependency is the wrong direction for this great chat client. There is also a corporate side of Zstd project imposing goals of free, libre culture and destroying other free software with imperative things (breaks portability, ignores backwards compatibility, and replaces existing services, forcing into adoption)!

So in conclusion this project should continue to allow other compression algorithm s has it was in the past

Cheers Irelativism

[flashcode]

Hi,

Such dependency can be made optional, but was forced as hard dependency because it leads to more complicated code, for example some values of options would become invalid, and this could cause problem when you upgrade to a new version not supporting zstd if you use it in options.
So technically possible, would be done only as last resort if I have no other choice.

By the way, I'm curious about licensing issues with zstd, it's licensed under BSD, what's the issue with this?
And what about destroying other free software with imperative things? Never seen such thing on their website.

[irelativism]

Hey thanks for the quick reply,

There is no problem with licensing Zstd, is FOSS, so you probably misread/misunderstood my point never stated such. In suma, forcing Weechat to depend on it, is problematic and it goes away from the Unix way.

Regarding your questions, and for me to be able to answer, I would suggest for a different approach from the opposite perspective on this matter. The problem here is not if anything wrong with Zstd but what happens when there will be, modular design is important for a reason and the referenced project is already going into the wrong direction by has stated breaking portability, ignoring backwards compatibility, and replacing existing services, that is why many people have changed focus to different algorithm, given its unnecessary and really said project just pushed those changes to force into its adoption.

So has you can see my friend the problem is not what is wrong with Zstd but making Weechat project resilient to when something happens or will be wrong with it. Hard dependencies without need are never a wise decision, and the consequences of it are already showing. So for this reasons has of now we decided to remove newer versions of Weechat from our repositories until hard dependency is removed.

Cheers Irelativism

[flashcode]

After investigation, unlike some other dependencies, it was not so hard to make it optional, so I just did it.

Now to build without zstd you must do this with cmake:

cmake .. -DENABLE_ZSTD=OFF

By default zstd is enabled and if not found, the build fails.

Out of curiosity, what's the distro where you don't want to build with zstd?
(I see on Debian that zstd is widely used in the distro, so this dependency should not be a problem).

[irelativism]

Cool thank you very much, truly appreciated. Its a shame I don't have skills to have made a PR for this maybe one day with you mentorship, Happy to help you out on any trivial jobs you might have for me or need help/dont have the time for etc. My email is irelativism@riseup.net if you wish to contact me with list or task I might be able to help with. Cheers

[eli-schwartz]

Out of curiosity, what's the distro where you don't want to build with zstd?
(I see on Debian that zstd is widely used in the distro, so this dependency should not be a problem).

https://sysdfree.wordpress.com/2020/01/04/293/

It's... a very unusual website. If you read some of the other blog posts there you'll see a lot of alarming statements. https://sysdfree.wordpress.com/2023/07/15/373/ is another fascinating one.