Re: Future of Wireshark's shared library ABI stability

[Roland Knall <rknall () gmail com>]

To be quite honest, I asked the developers myself. In this case they are a
group of students who implemented that utility and did not know better.
Personally I would much rather have new developments added to the main
repository than be implemented as standalone. And as Guy rightfully
guessed, the main reason for them doing it this way was to basically
provide a different UI for the dissection engine with a little bit
different output info. Hope that answers your question as well Joao. Not
saying it was correct doing it like this, just that it happened. Sadly,
this utility is used by quite a few people and will not get an update
anytime soon. The version I know of is maintained behind closed doors and
they are currently changing the sourcecode to adapt for the ABI change.

Just to clarify, I do not think that people should be using those
libraries. But it is a know issue that they do. And forcing them by
breaking mid-release is not a good idea in my point of view. Now breaking
between major releases - I am all for that (within reason).

Am Do., 20. Jan. 2022 um 22:25 Uhr schrieb Guy Harris <gharris () sonic net>:

> On Jan 20, 2022, at 1:12 PM, Roland Knall <rknall () gmail com> wrote:
>
> > But it was implemented by utilizing heavily a wireshark installation
> including libwireshark and libwsutil
>
> So why, *other than "because it uses Wireshark libraries intended to
> provide directly useful services such as reading capture files or
> dissecting packets and that use libwsutil"*, would some program outside of
> Wireshark use wsutil?
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe