[Roland Knall <rknall@xxxxxxxxx>]

> Am 20.12.2023 um 22:02 schrieb João Valverde <j@xxxxxx>:
> 
> 
> 
>> On 20/12/23 20:52, Roland Knall wrote:
>> 
>> 
>> 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.
> 
> So people can link to our libraries to write other projets? And expect it to work reliably? That is news to me. I have made this question many times over the years but I guess I was not worthy of a clear answer until now.
> 

I am not saying they should do it or that I appreciate it happening. All I am saying is that it happens and is happening and we did not put a stop to it in time. Should they expect it to be reliable? Of course not as I answered also in other threads on this matter. But at the same time I see no point in having them hit a wall face on, rather work in such cases where we know about it, to ensure them moving to a saner approach. 


>> 
>> 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.
> 
> I don't know what libvirt are doing specifically, a plugin is a plugin, something very eerie and mysterious seems to be afoot over there, but I will investigate, out of curiosity

Nothing mysterious just a very weird approach on how to keep those two parts compatible. My guess is, that they do it to avoid dead code paths and a lot of exception/decision handling when dealing with version differences. 

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