> Am 20.12.2023 um 22:02 schrieb João Valverde <j...@v6e.pt>: > > > >> On 20/12/23 20:52, Roland Knall wrote: >> >> >> Am Mi., 20. Dez. 2023 um 21:24 Uhr schrieb João Valverde <j...@v6e.pt>: >> >> >> >> 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@wireshark.org> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe >> >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
