Am Mi., 20. Dez. 2023 um 21:24 Uhr schrieb João Valverde <
j@xxxxxx>:
On 20/12/23 16:06, Roland Knall wrote:
> 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.
I don't know what you are trying to get at. I'm not trying to say what
Debian should or shouldn't do. They are free to decide for themselves.
I would never presume to tell them what they should do, although I have
strong opinions on that. There are lots of problems with their package
but that is something to be discussed in the Debian bug tracker, not
here. This project isn't part of Debian. This fact seems to be lost on
some people.
The idea Balint had is, that no matter if you are using the official package or build it yourself with our repository, you will not be locked out of updating the package or distribution, and most certainly it will not lead to any issues with package management. This might be a speciality of Debian, but I think it is something we can support as it does not really hinder us, except for the issue with the lib manifest, which now seems to be resolved. And I do think that supporting this choice by our users is something that is worth supporting.
>
> 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 don't understand what any of this means, sorry. I'm not being
facetious, could be my own fault. I have written many Wireshark plugins
so I know a lot about that topic. What problems are the libvirt people
experiencing that I am not? What strange and mystical path is this that
we are on? Why did we mess up? Please enlighten me. Really, I would like
to know so we can have a fruitful conversation about this because right
now I am really confused.
We made the initial mistake of staying in a patch that allowed for a situation like this to occur. We made sure that you could link against our libraries and build your own projects from it. To revert this now, will lead to issues and pains in various places outside of the project, which might not seem to be a big thing initially, but it can hurt us in the long run. Think the whole Gnome 2/3 transition which drove quite a few people made, although they had a good reason for it.
I agree with you btw on the fact that the way libvirt does this plugin is not a good one. I think they should stop pretending to be extra smart in this case and revert to a model, where one plugin version may be compatible with multiple libvirt versions or vice versa. That would resolve this whole issue. But unless we are willing to fight this fight (and I for one am not particularly interested in that pandora's box) I do not see a reason why we should actively undermine their approach, just for the sake of "being right". I agree that it would be a better approach, but it would also open up quite a few birthing pains and that at least would violate our "no breaking unless major version release" policy. Another one of those we never actively charted down, but try to uphold.
Hope this clears up the point I was trying to make
kind regards
Roland
___________________________________________________________________________
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