On Thu, Mar 15, 2018 at 04:46:18AM +0000, Stephen Donnelly wrote:
> On Mar 14, 2018, at 1:41 PM, Gerald Combs <gerald@xxxxxxxxxxxxx> wrote:
>
> >As discussed previously we'll drop support for Qt 4 and GTK+ in the master
> >branch after master-2.6 is created. Unless there are strong objections I'd like
> >to bump the minimum GLib version to 2.32.
>
> As a note, Redhat Enterprise Linux 6 is in Maintenance 2 support until late 2020, and only ships Glib 2.28 afaik.
Yep, RHEL6 still ships GLib 2.28 according to
https://wiki.wireshark.org/Development/Support_library_version_tracking#RHEL.2FCentOS
http://rpms.famillecollet.com/rpmphp/zoom.php?rpm=glib2
EPEL6 does not have a newer glib2 either, it does Qt 5.6.1 though so in
theory RHEL6 could still be supported.
> Would this mean no Wireshark 2.6 support for EL6 based Linux distributions?
>
> If EL6 support is still desirable, an option might be developing to the Glib 2.32 interface, but providing wrappers (polyfil) for the few bits of Glib used by Wireshark that are different or not available in 2.28.
Providing polyfills might be possible. I had a look at the changelogs
(do note that odd GLib versions are development versions / even are
stable) to find desirable API extensions that are not in 2.28:
https://abi-laboratory.pro/tracker/changelog/glib/2.32.4/log.html
https://abi-laboratory.pro/tracker/changelog/glib/2.30.3/log.html
- 2.31.8: g_hash_table_add, g_hash_table_contains
- 2.31.6: g_[s]list_free_full
- 2.29.16: g_ptr_array_add_full
- (2.29.10: g_hash_table_iter_replace)
The first three would be very nice to have and it should be reasonable
easy to fill them in, but at the same time it would be nice to avoid
having to include a glib-compat header in every file that use these.
Any comments regarding this?
--
Kind regards,
Peter Wu
https://lekensteyn.nl
