[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#811036: wireshark-qt: aborts immediately



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.

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

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.

Ideally this plugins would be shipped separately as each of them pull 
different dependencies... but we had quite some complaints about this so far.

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.

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.

Kinds regards, Lisandro.

-- 
15: Que es el "Correo Electronico"
    * El correo que te llega por la corriente
    Damian Nadales
    http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: