Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#65266 - [gst-plugins-good] Mandatory QT5 deps

Attached to Project: Arch Linux
Opened by Victor Bessonov (Unb0rn) - Saturday, 25 January 2020, 10:16 GMT
Last edited by Jan Alexander Steffens (heftig) - Thursday, 19 March 2020, 14:40 GMT
Task Type General Gripe
Category Packages: Extra
Status Closed
Assigned To Jan Alexander Steffens (heftig)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No

Details

Description:
After today's (1.16.2-2) update I've found I need Qt5 framework as deps for this package. It adds like 100Mb of absolutely unnecessary bloat to my system. Is it a bug? Do we really need whole qt5 on every machine for running gstreamer now?

Additional info:
* package version(s)
1.16.2-2
This task depends upon

Closed by  Jan Alexander Steffens (heftig)
Thursday, 19 March 2020, 14:40 GMT
Reason for closing:  Fixed
Additional comments about closing:  gst-plugins-good 1.16.2-3
Comment by Roman Brusentsov (Gavcheg) - Saturday, 25 January 2020, 18:01 GMT
Yes, why this commit https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/gst-plugins-good&id=707e30c572df1355338afd8315cfa2a550ae6cf5 adds qt5 stuff to depends? It's totally unnessesary. But if it is, there need to explain.
But i hope, this is simple mistake.
Comment by Eli Schwartz (eschwartz) - Sunday, 26 January 2020, 01:42 GMT
  • Field changed: Summary (Mandatory QT5 deps → [gst-plugins-good] Mandatory QT5 deps)
  • Field changed: Architecture (x86_64 → All)
The first mistake you made was not actually stating the package you were talking about at all. You're lucky someone else responded and mentioned the package name.
Comment by Peter Weber (hoschi) - Sunday, 26 January 2020, 14:45 GMT
Hello!
I'm also not using applications based on Qt and recognized the unnecessary dependency. I assume sole users of Qt also don't appreciate the addition of Gtk. Probably we can move Gtk and Qt to optdepends and/or makedepends?

Thank you :)
Comment by Costachescu Cristinel (T3STY) - Thursday, 30 January 2020, 02:44 GMT
Hi, could you please not bloat our systems with unnecessary extra dependencies?

As described in the upstream FAQ about gstreamer dependencies:
https://gstreamer.freedesktop.org/documentation/frequently-asked-questions/dependencies.html
> ...
> GStreamer has only a few mandatory dependencies: GLib 2.0, liborc, and very common stuff like glibc, a C compiler, and so on. All other dependencies are optional.
> ...
>
> Does GStreamer depend on GNOME or GTK+?
>
> No, it's just that many GStreamer applications, including some of our sample ones, happen to be GNOME or GTK+ applications, but there are just as many using the Qt toolkit or written for Mac OS/X, Windows, Android or iOS.

There is no reason to put any of GTK or Qt as dependencies, either optional or mandatory, for the final binaries of gst-plugins-*. These libs don't even show a UI by themselves in the first place, so why would they depend on any GUI toolkit ??
Comment by Peter Weber (hoschi) - Thursday, 30 January 2020, 07:08 GMT
Don’t worry. I‘m sure it is just an oversight.
Comment by Ryan Farley (rcf) - Friday, 31 January 2020, 20:12 GMT
T3STY: that's referencing the core framework. It doesn't depend on any particular GUI toolkit, but the *plugins* absolutely do, in some cases, so optional dependencies make perfect sense.
Comment by Andrew (abrouwers) - Thursday, 06 February 2020, 11:58 GMT
Looking at others, it seems that both debian and fedora split out the plugins:

https://packages.debian.org/bullseye/gstreamer1.0-qt5
https://src.fedoraproject.org/rpms/gstreamer1-plugins-good/blob/master/f/gstreamer1-plugins-good.spec#_120

If Optional doesn't work, might that be a simple solution - just splitting the plugin to a small package to provide the additional functionality?
Comment by Peter Weber (hoschi) - Thursday, 19 March 2020, 11:45 GMT
Heftig has probably already fixed it?

But the newly installed packages are still present:
$ pacman -Q | grep -i qt
qt5-base 5.14.1-3
qt5-declarative 5.14.1-1
qt5-wayland 5.14.1-1

I expected that a 'pacman -Qdt' will name them and therefore I would remove them with 'pacman -Rns qt5-base qt5-declarative qt5-wayland'. But 'pacman -Qdt' doesn't list them. Nothing seems to require them but themselves. It looks like qt5-wayland and qt5-base have an optional cyclic dependency on each other and qt5-wayland requires qt5-declarative, which requires qt5-base.

Question: Am I right, that pacman isn't able to discover this and I have to remove them anyway?

Loading...