On 21/01/22 09:44, Bálint Réczey wrote:
João Valverde <j@xxxxxx> ezt írta (időpont: 2022. jan. 21., P, 1:29):
On 20/01/22 21:24, Bálint Réczey wrote:
Hi Guy,
Guy Harris <gharris@xxxxxxxxx> ezt írta (időpont: 2022. jan. 20., Cs, 21:52):
On Jan 20, 2022, at 12:34 PM, Gerald Combs <gerald@xxxxxxxxxxxxx> wrote:
Q: Should *wsutil* be part of that stable ABI?
Debian, Ubuntu and (according to rpmfind.net) OpenSuSE and Mageia treat it as such. It would be helpful to know what non-Wireshark packages depend on wsutil in those distributions and elsewhere.
...and, if there are any, to know *why*.
It seems libvirt's plugin needs wmem_alloc(), for example:
https://gitlab.com/wireshark/wireshark/-/issues/17889
How is that relevant?
The answer to the question that was asked is: exactly zero Debian
packages have a dependency on your libwsutil/libwireshark/libwiretap
packages.
In gitlab issue I already mention libvirt as a packaged thus I had the
impression that this one was covered:
https://gitlab.com/wireshark/wireshark/-/issues/17822#note_815677078
It is factually incorrect to state that nothing depends on our
libraries in Debian:
root@73c5830ef791:/# apt-cache rdepends libwireshark14
libwireshark14
Reverse Depends:
...
libvirt-wireshark
root@73c5830ef791:/# cat /etc/issue
Debian GNU/Linux 11 \n \l
root@b396a73800b0:/# apt-cache rdepends libwireshark15
libwireshark15
Reverse Depends:
...
libvirt-wireshark
root@b396a73800b0:/# cat /etc/issue
Debian GNU/Linux bookworm/sid \n \l
# apt-cache show libvirt-wireshark
Package: libvirt-wireshark
Source: libvirt
...
Description: Wireshark dissector for the libvirt protocol
I'm not sure how you checked, but this is what I saw on current stable and sid.
I used apt-rdepends to check. Maybe I checked a different release. I
stand corrected in any case. There is one package that depends on
libwireshark in Debian. I was not aware libvirt-wireshark existed in
Debian.
However as I have repeatedly tried to explain plugins are a misdirection
to the discussion. It is very curious that libvirt-wireshark depends on
libwireshark14 *only*, since as a dissector plugin it cannot work with
only libwireshark14. It needs the rest of Wireshark as well to drive it
and be useful (GUI or CLI). I fail to see how libvirt-wireshark having
libwireshark as a dependency is useful in any way and not just polluting
the system of Debian users who install libvirt-wireshark. They would
have to install the rest of Wireshark manually anyway, which in turn
would automatically install libwireshark.
If you want to see what a properly packaged non-trivial application for
Debian looks like check out Geany[1] for example. It also uses shared
libraries internally and has a plugin system.
Generally I'm open to learn new things, but after not being able to
find reverse dependencies of libwireshark* I hope you don't mind that
I take your advice on packaging with a grain of salt.
From Geany's description:
About ----- Geany is a small and lightweight integrated development
environment. It was developed to provide a small and fast IDE, which
has only a few dependencies from other packages. Another goal was to
be as independent as possible from a special Desktop Environment like
KDE or GNOME. So it is using only the GTK+ toolkit and therefore you
need only the GTK+ runtime libraries to run Geany.
As you can see Geany's goals are very different from Wireshark's and
Geany not providing shared libraries aligns with having minimal
dependencies.
Speaking of packaging non-trivial applications I maintained systemd
and glibc among other things in Ubuntu in the last few years thus I
have some experience in the area.
IMO it is easier mentally to have a single library ABI policy because
we ship only public libraries. Having a more relaxed private shared
library policy would make it easier to make mistakes.
I have no idea what you are trying to say here. The libraries were not
intended to be public until you stepped in, by the way.
I'm wondering if others did understand what I tried to say here.
As you pointed out in [2] there were recurring queries to make the
then private libraries more widely available and I accept the credit
or blame to help a lot in making the ABI stable and available for
external projects.
Also if libwsutil (with wmem_alloc) became private in 3.6.x then
libvirt had a much harder time continuing the maintenance of their
plugin starting with 3.6.0.
No. Nobody said anything about 3.6.x and none of that is true.
This was a hypothetical example of what would happen if we moved
libwsutil to a private library location with no ABI stability promise.
And wmem_alloc did move to libwsutil in [3].
Regardless if the libraries are public or private and what that means we
will continue to provide the pkg-config file for anyone to use them. So
nothing would change for libvirt. Obviously more stability is better,
everyone recognizes that, as long as that doesn't impinge on innovation,
security, and isn't an undue burden on the project's resources.