Re: Future of Wireshark's shared library ABI stability

[Roland Knall <rknall () gmail com>]

To be fair, there are two things to consider here. The status quo and the future direction. The second one should not 
be to develop those libraries independently. I totally agree with you that this should not be our scope. 

The status quo though is a different one. I do feel that we should bring the project into a direction, where it no 
longer needs to be considered, but this should be done carefully like you did in the past. We could break harder if we 
come up to the next major release. 

We could start a talk, if the next version in the summer should be such a release and if it would be opportun to change 
some bigger things that bother us. E.g. default settings or default layouts for example. And with such a discussion I 
would also argue that we could have a discussion about the expected contents of our packages

Cheers
Roland

> Am 22.01.2022 um 14:05 schrieb João Valverde <j () v6e pt>:
>
> Regarding questions I would like to know if is Wireshark is developed, including each of the three existing 
> libraries, for other projects to add as dependencies to their software stack. It is possible I need to adjust my 
> understanding and expectations accordingly, and I will do so.
>
> External plugins developed independently are not really relevant to this discussion. Plugins are not independent 
> projects in a technical sense, they depend on Wireshark as a whole and not only any particular Wireshark library.
>
> If we wanted to release system shared libraries, in the style of libpcap like Balint intends, I think it would be 
> important to split them out of the main repo, with their own build system, lifecycle, clearly defined purpose, 
> versioning, API/ABI policy, release cadence, etc. It would also be important to restructure the source tree, at a 
> minimum to add an include folder for each library.
>
> This would be how to develop, maintain and release a library properly, in my opinion. That's why I said in the Gitlab 
> issue a shared library should be implemented bottom up and not the other way around, like it was done here.
>
> > On 20/01/22 20:34, Gerald Combs wrote:
> > If I understand the discussion in issue 17822 and here, we're looking at the following questions (feel free to 
> > correct me where needed):
> >
> > Q: Should we commit to a stable ABI between minor releases?
> >
> > I think everyone agrees that we should, or at least that it's a worthwhile goal.
> >
> > Q: Should *wsutil* be part of that stable ABI?
> >
> > Debian, Ubuntu and (according to rpmfind.net) OpenSuSE and Mageia treat it as such. It would be helpful to know what 
> > non-Wireshark packages depend on wsutil in those distributions and elsewhere.
> >
> > Q: What's the best way to ensure stability?
> >
> > That's a tricky one. We did so in the past using abi-compliance-checker, but that was removed in 6e5ba74b. I think 
> > it would be worthwhile to try adding it back in a more simplified form for release branches, but I'm not sure when I 
> > would have time to work on that.
> >
> > > On 1/20/22 7:29 AM, Roland Knall wrote:
> > > For clarification: " but the change should most certainly happen with a version beyond 3.6" means, that the break 
> > > should be reverted for 3.6.x, but it should be put in place for -dev to be in the next major release
> > >
> > > cheers
> > >
> > > > Am Do., 20. Jan. 2022 um 16:28 Uhr schrieb Roland Knall <rknall () gmail com <mailto:rknall () gmail com>>:
> > >
> > >     I think it is reasonable to assume that libraries provided with the project are being used by external 
> > > programs. I know one utility which is being used in a rather closed-off community (but nonetheless widely adopted 
> > > by around 200-300 people), which got broken by this. Their solution is to stay on 3.4 until either 3.6 is fixed or 
> > > the utility (which probably will be done in this case).
> > >
> > >     I also think it is the right thinking to allow libraries and more specifically ABI breaks between releases. But 
> > > those should never occur in a maintenance release, which is what happened here if I got the gist of it. If the 
> > > break would be between 3.4.x and 3.6.0 it would be fine by me. But breaking between 3.6.0 and 3.6.1 should not 
> > > happen. I consider this an issue that must be fixed - but the change should most certainly happen with a version 
> > > beyond 3.6.
> > >
> > >     And just additionally my 2 cents. Please always consider that although the download rates of Wireshark are 
> > > mind-blowing and wonderful, the adoption within companies might be even greater with special build versions. There 
> > > exists many reasons for those versions, be it not enough resources available to bring changes to mainline or having 
> > > code and adaptations which are for whatever (legal mostly) reasons not able to be publicly available. Changes like 
> > > these i would see as a risk to those practices, and one of the reasons Wireshark has such a good standing within 
> > > the community are our policies for long-time stability and maintainability.
> > >
> > >     Just my own thoughts on this.
> > >     cheers
> > >     Roland
> > >
> > > >     Am Do., 20. Jan. 2022 um 13:42 Uhr schrieb Bálint Réczey <balint () balintreczey hu <mailto:balint () 
> > > > balintreczey hu>>:
> > >
> > >         Hi All,
> > >
> > >         João shared his opinion about the project's commitment to maintain
> > >         stable shared library ABI within stable branches:
> > >         https://gitlab.com/wireshark/wireshark/-/issues/17822 
> > > <https://gitlab.com/wireshark/wireshark/-/issues/17822>
> > >
> > >         I believe the current practice is reasonable and beneficial enough for
> > >         many parties to warrant the work, but I could be wrong.
> > >
> > >         Comments are welcome.
> > >
> > >         Cheers,
> > >         Balint
> > > ___________________________________________________________________________
> > >         Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org <mailto:wireshark-dev () wireshark 
> > > org>>
> > >         Archives: https://www.wireshark.org/lists/wireshark-dev <https://www.wireshark.org/lists/wireshark-dev>
> > >         Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev 
> > > <https://www.wireshark.org/mailman/options/wireshark-dev>
> > >                       mailto:wireshark-dev-request () wireshark org <mailto:wireshark-dev-request () 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-request () 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-request () 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-request () 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-request () wireshark org?subject=unsubscribe