I'm not sure why libvirt dissector users should be "their users". In my eyes they are very much our users as well since they use Wireshark extended with the plugin and I'm happy that they get the best service.
>
> Am Mi., 20. Dez. 2023 um 19:57 Uhr schrieb Bálint Réczey <
balint@xxxxxxxxxxxxxxx>:
>>
>> Roland Knall <
rknall@xxxxxxxxx> ezt írta (időpont: 2023. dec. 20., Sze, 17:06):
>> >
>> > Ok, I am not ignoring those points, as I think those points are valid. It makes sense, that building debian packages from the repository should behave in the same way as it does with the overall projects. Now, one could argue, that having multiple packages could have been avoided in the beginning or it should be changed, that would be a valid discussion being had, but I do not think it invalidates those points and arguments. Yes, debian is different but it is also the base (through ubuntu) for the majority of linux distributions as wells Microsofts own variety in wsl2 (at least if you go with the default one), and therefore it should be considered as such.
>> >
>> > The examples listed here are valid, although not very widely distributed ones. Just because they are not distributed with a debian distribution is not a counterargument to the update argument Balint raised. I am also not certain, why arguing against that on the pure merit of not being part of a distribution is a technical argument.
>> >
>> > The libvirt plugin is a valid example of where we messed up. And with we I mean the whole project. We provided this path and we kept it maintained for far too long, but it is here now and a solution needs to be found. We started on that road with stating that we allow invalidating the api in major version releases and also minor version releases to some extend. The argument, that libvirt is still doing something they should not be doing is valid. But the solution here is not hindering the compatibility, but getting in touch with them and figuring out how to do it properly together. We created this path, we should not destroy it but help others find a safer route. And libvirt is indeed being used by quite a few people.
>>
>> I generally agree with you on the other points, but why do you believe
>> we messed up? We allow and help external plugin development and did it
>> in a widely followed way of maintaining the shared library ABI and
>> headers. I think we did great in that regard and libvirt just
>> maintains an external plugin, the way we advertised to be possible. I
>> also think that there is no better way, but I'll be ready to be proven
>> wrong.
>>
>> We talked about the libvirt plugin and this is why I believe that the
>> status quo is the best for the users:
>>
https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1660815830
>>
>> I also reached out to them prior to our conversation and they
>> elaborated on their decision to ship the plugin separately and I'm
>> convinced that that's the best option of the users:
>>
https://gitlab.com/libvirt/libvirt/-/issues/106#note_488155469
>>
>> Cheers,
>> Balint
>>
>> >
>> > As for the straw man argument, the Code of Conduct defines how collaboration and social interaction should happen. As such, I do not see this as a straw man argument but a valid reason, why Balint chose the paths he chose in the past and why this package exists as it does now. In a technical discussion it is as important to understand why somebody did something as it is to listen to each others arguments. And this gives reason to why the current situation is what it is, and should be validated in choosing a solution for the future.
>> >
>> > kind regards
>> > Roland
>> >
>> > Am Mi., 20. Dez. 2023 um 16:32 Uhr schrieb João Valverde <
j@xxxxxx>:
>> >>
>> >> Keep in mind I am just a user but I'm not one to skip a good technical
>> >> discussion.
>> >>
>> >> I'm ignoring your other points on purpose, there is only so much I can
>> >> handle in one sitting.
>> >>
>> >> On 20/12/23 13:24, Bálint Réczey wrote:
>> >> > Having separate packages follows Debian packaging best practices and
>> >> > served external projects extending wireshark such as netexpect (
>> >> >
https://tracker.debian.org/news/505793/accepted-netexpect-018-1-source-i386/
>> >>
>> >> I lookup up what netexpect is. Your link is from 2011. Actual link
>> >> (
https://tracker.debian.org/pkg/netexpect) says "This package is not
>> >> part of any Debian distribution." OK... Starting strong there.
>> >>
>> >> > ) and the separately maintained libvirt dissector (
>> >> >
https://packages.debian.org/unstable/libvirt-wireshark ).
>> >>
>> >> You keep coming back to the libvirt plugin. What do you expect to prove
>> >> with this? You really think maintaining separate Debian packages is a
>> >> benefit to a Wireshark plugin? I'm sorry, I don't know how to respond to
>> >> non-sensical statements. Do you want me to build the libvirt-wireshark
>> >> plugin against our RPM package just to put this argument to rest once
>> >> and for all?
>> >>
>> >>
>> >> > As I interpret our Code of Conduct collaboration with other projects
>> >> > is highly encouraged no matter if Wireshark builds on them or they
>> >> > build on Wireshark. I acted according to that in maintaining the
>> >> > Debian packaging both here and in the official Debian repository.
>> >> >
>> >>
>> >> Straw man argument. No one said collaboration is bad.
>> >>
>> >> ___________________________________________________________________________
>> >> Sent via: Wireshark-dev mailing list <
wireshark-dev@xxxxxxxxxxxxx>
>> >> Archives:
https://www.wireshark.org/lists/wireshark-dev
>> >> Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
>> >> mailto:
wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>> >
>> > ___________________________________________________________________________
>> > Sent via: Wireshark-dev mailing list <
wireshark-dev@xxxxxxxxxxxxx>
>> > Archives:
https://www.wireshark.org/lists/wireshark-dev
>> > Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
>> > mailto:
wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>> ___________________________________________________________________________
>> Sent via: Wireshark-dev mailing list <
wireshark-dev@xxxxxxxxxxxxx>
>> Archives:
https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
>> mailto:
wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe