Wireshark mailing list archives
Re: Qt availability changes
From: Peter Wu <peter () lekensteyn nl>
Date: Tue, 28 Jan 2020 00:42:32 +0000
On Mon, Jan 27, 2020 at 09:53:11PM +0100, Roland Knall wrote:
Well it took me a while to read through all the comments.
Indeed, some highlights: * A Qt community contributor suggests potential adverse effects for the Qt Company such as forking and less contributions. https://lists.qt-project.org/pipermail/development/2020-January/038337.html * Another contributor expressing similar concerns, and worrying about "important" bug fixes. https://lists.qt-project.org/pipermail/development/2020-January/038344.html * A note about transfer of ownership rights to the KDE Free Qt Foundation. Most likely does not cover binaries, but source code. https://lists.qt-project.org/pipermail/development/2020-January/038341.html * A concern about Qt quality as shipped on Linux with some numbers about changes in releases to back it up. https://lists.qt-project.org/pipermail/development/2020-January/038388.html
First of all, I understand their - Qt's - reasoning. It makes sense from a business side of things, and they are getting rather big. Developing that framework is not the easiest task and they need money (sounds too familiar). This sucks, but I imagine we can keep the impact for our user-base to a minimum.
I think it is worth emphasizing that it only affects users who build or develop Wireshark from source. The final Wireshark installer will still bundle the Qt bits.
From an installation point of view, basically you have two options: a. Go with the official installer and register for an account, or b. use brew/port on Mac and chocolatey/vcpkg on Windows. b. does not require registration, as chocolatey/vpckg/brew/ports build themselves and they do not force the registration policy. They also tag releases, which means that we could tag to a specific release for each platform. After reading a lot of messages on the mailing list, it seems that the main difference for LTS releases will be that additional to security fixes, adaptions of changes (aka compiler changes for instance) will no longer be available in older versions. I assume we will have the option to build a version of Qt ourselves which we could than add to the installation bundle. That option can be used from -dev or always the latest tagged release version. For Windows/Mac users it will not make much difference, as most Qt-based OSS projects don't focus on using a system-wide Qt version anyway and are fine with using a package-distributable version. It might present us with headaches in regard of supporting Wireshark on older Mac/Windows versions though, and makes our job a little harder. It also introduces a wider range of possible bug-hunts.
The main problem I see is it basically forces us to use the latest Qt version which makes supporting older Linux distributions somewhat harder. Based on the Qt version history [1], it looks like non-LTS versions are supported for 1 year. Typical Linux distributions have a longer lifetime. [1]: https://en.wikipedia.org/wiki/Qt_version_history#Qt_5 The Qt project is still committed to providing security updates, so that should not change the situation for Linux distribution maintainers. Debian for example typically does not update the Qt version even though there may be dozens of usability bug fixes.
On the - user wants to develop a dissector - route, yes I agree, this makes our lives harder. Just developing a small dissector quickly will not be as easy as it might seem today (it isn't today as easy as it should be also, but this is a different issue). On the other hand, a lot of users struggle with today's approach as well. For the rest we can map out the chocolatey/vpckg/brew/ports route. Or switch to Lua dissectors, where we might need to find a way to package and distribute them properly. Finally, I would not call it a day yet. Qt has become a very strategic project for a lot of people. I could imagine, that the outcry over this decision will be as big as the one 2015 over the first attempt to close down the installer. I could imagine, that they will backpedal the ideas a little bit in the near future, although I will not betting on it. Let's hope they at least give the LTS route another thinking and come up with a different solution. For the reasons mentioned above, I could live without the binary releases, having no longer an easily accessible LTS branch does hurt though.
The LTS branch is not just 'no longer easily accessible', it will simply be unavailable for non-commercial users. The Qt company wants OSS developers like us to use the latest version and report back issues and such. Which I already did in the past, including patches...
Overall, I hope the impact will be - if anything - as small as possible and affect us as the core's more than our users. cheers Roland Am Mo., 27. Jan. 2020 um 21:37 Uhr schrieb Graham Bloice < graham.bloice () trihedral com>:On Mon, 27 Jan 2020 at 20:06, Gerald Combs <gerald () wireshark org> wrote:The Qt Company recently announced upcoming changes in the distribution of their official binaries: https://www.qt.io/blog/qt-offering-changes-2020 https://lists.qt-project.org/pipermail/development/2020-January/thread.html#38316 Two of the changes adversely affect how we develop and build Wireshark, primarily on Windows and macOS. First, downloading official releases from qt.io will require logging in with a Qt account. How much of an issue is this for people developing Wireshark on those platforms? Is it enough to warrant switching to a different, unofficial source for Qt binaries? I'm not really thrilled about the prospect of Qt salespeople pestering someone who just wants to build a Wireshark dissector. Second, LTS releases will no longer be open source starting with Qt 5.15. We currently ship the latest LTS version of Qt with our Windows and macOS packages. I'm not sure how we're going to handle this in the future.
We currently use 5.12 LTS which is supported until the end of 2021, so that is still two years. Hopefully a reasonable solution becomes available before then.
Uggh. Really unhelpful. I fail to see how requiring Open source projects to follow effectively the HEAD of the CURRENT release is going to make things better. As folks noted in the thread you linked to, how will CI systems handle this?
Good question... I have automated Qt installation for Travis CI with https://gitlab.com/wireshark/wireshark/blob/master/tools/travis-install-qt-windows.sh downloads the online installer, and just caches the installed tree. However if credentials are suddenly necessary, then we would have to add it somehow. Most likely with some throw-away email, but I am not sure if that violates some usage terms. If that does not work, we could archive the tree and cache it on our server. If that does not violate distributions rights... Kind regards, Peter ___________________________________________________________________________ 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
Current thread:
- Qt availability changes Gerald Combs (Jan 27)
- Re: Qt availability changes Graham Bloice (Jan 27)
- Re: Qt availability changes Roland Knall (Jan 27)
- Re: Qt availability changes Guy Harris (Jan 27)
- Re: Qt availability changes Peter Wu (Jan 27)
- Re: Qt availability changes Graham Bloice (Jan 28)
- Re: Qt availability changes Guy Harris (Jan 28)
- Re: Qt availability changes Roland Knall (Jan 28)
- Re: Qt availability changes Roland Knall (Jan 28)
- Re: Qt availability changes João Valverde (Jan 30)
- Re: Qt availability changes Roland Knall (Jan 30)
- Re: Qt availability changes Roland Knall (Jan 27)
- Re: Qt availability changes Graham Bloice (Jan 27)