Re: Bug#811036: wireshark-qt: aborts immediately
Disclaimer: I don't use an awful lot of Qt/KDE applications so I don't
really know much about what's going on.
Lisandro Damián Nicanor Pérez Meyer writes:
> Hi everyone!
>
> Long story short: whenever we push Qt 5.6.x to unstable this will get "fixed",
> at least for some time. Long story below.
>
> On Friday 15 January 2016 11:20:59 Bálint Réczey wrote:
>> Hi Olaf,
> [snip]
>> > I would argue that showing the GUI is a prerequisite for any of the
>> > functionality. The GUI isn't shown, hence, zero functionality.
I'd like to repeat this point: if a GUI application cannot show its GUI
it's non-functional.
> [snip]
>
>> It still had wireshark manpage which is not present in wireshark-gtk and
>> can be useful, but I see your point. :-)
>>
>> > I don't know how wireshark-qt obtained the dependency but it needs that
>> > xcb plugin very badly to provide any functionality. Can't you add the
>> > libqt5xcbqpa5 dependency to wireshark-qt (even if only temporarily)?
>>
>> I can, but fixing that a fixed libqt5gui5 would reach testing as fast a
>> fix in wireshark-qt, thus I would like to as KDE Maintaintainers to share
>> their thoughts first.
>
> And here's the main issue: Qt 5 now works with plugins and not necessarily
> just on X. That means that as long as you don't depend on X-exclusive stuff
> you can run a Qt5 app on the frambuffer, Wayland and other interesting
> platforms.
I don't really care whether Qt used plugins or libraries but for GUI
applications to show anything, they would need at least one of the
plugins, right? So a
Depends: this-plugin | that-plugin | yet-some-other-plugin
would be required. Now that really sucks from a package maintainer
point of view. It would be more convenient te be able to say something
like
Depends: qt-render-plugin
which would be a meta-package that has the first Depends: that lists all
the available alternative in a suitable order and is maintained by the
Qt/KDE maintainers.
# I realize that the "suitable order" bit is not trivial.
> So, strictly speaking, libqt5xcbqpa5 (which should have been named something
> like qt5-xcb-platform-plugin) is not a strict dependency, and thus the
> recommendation. And people not using recommendations should handle it by hand.
Like I said, I consider a GUI application that cannot show itself when
the Recommends: are not installed broken ;-)
> Ideally this plugins would be shipped separately as each of them pull
> different dependencies... but we had quite some complaints about this so far.
That suggests you're violating the principle of least surprise :-)
> We checked that if we push all the plugins to libqt5gui5 the total amount of
> extra dependencies is ~3MiB consisting purely in libs (ie, not dragging
> daemons nor any kind of apps) so we will go this way for the time being.
>
> If at some point the amount of extra dependencies increases significantly we
> will split them again. Time will tell.
>
>> IMO packages should not follow how Qt packages are structured to set
>> their dependencies, but Qt should provide helper scripts which set the
>> needed dependencies for the binary packages. Many other frameworks
>> do that.
That might be an alternative to my suggestion above.
> I'm interested in this, do you have an example for that? Remember we are
> talking about plugins here, not libs, so shlibs/symbols files will not work.
> But if there is a better way out I don't know it would be really cool to study
> it.
>
>> If the KDE team still decides to split the packages with no helper scripts,
>> please coordinate with reverse dependencies in advance to avoid bugs
>> like this one.
>
> The problem is: which ones? Whatever gets built just with Qt5 can run
> anywhere.
Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- EPSON AVASYS CORPORATION
Free Software Foundation Associate Member since 2004-01-27
Support Free Software https://my.fsf.org/donate
Support the Free Software Foundation https://my.fsf.org/join
Reply to: