Re: Qt availability changes

[Roland Knall <rknall () gmail com>]

Well it took me a while to read through all the comments.

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.

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

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.

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.
>
> 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?
>
> --
> Graham Bloice
> ___________________________________________________________________________
> 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