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.
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