So basically, if it is a GTK app we will have to either use GNOME or run it as a Flatpak?
Not at all. The “system policy and adopted ideology” is merely the fact that we like to keep our system lean and as free of bloat as possible. Therefore if something is commonly used has a plugin or so that pulls in a slew of dependencies, we try to split that plugin into a separate package so we don’t end up installing hundreds of megabytes of dependencies on the systems of people who will never use that particular functionality.
This goes for everything (e.g. in libreoffice, both the Qt and the GTK integration plugins are split into separate packages, python bindings to various KDE libraries are split into separate packages, …), but GTK related stuff happens to be affected to it a lot because GTK is bad code and its developers seem to love making everything depend on everything else - e.g. something that should really be lean (gdm) these days has a hardwired dependency on gnome-session. GTK is developed in the mindset of “GNOME is the world, therefore it’s not a problem at all if GTK Hello World pulls in 500 MB of dependencies”.
The solution to this is to split optional dependencies and add Requires: statements to spec files where the extra dependencies are needed.
dnf install package SHOULD always give you the package and everything it depends on. Usually that works, because rpm is good at figuring out dependencies - but sometimes it doesn’t because e.g. a plugin is loaded through dlopen (not causing a visible dependency), and an application crashes because it has some unnoticed dependency. When we get a report, we fix it by adding the needed dependency. But of course you might be the first person to notice, in which case you will see the bug before we had a chance to fix it.
While I can certainly understand that this causes some frustration with people maintaining affected packages (and yes, GTK applications happen to be hit by it most frequently: They’re most commonly used by people on GTK desktops, where those dependencies are installed because the desktop depends on them – and since few people use GNOME applications in KDE or LXQt, if you do that you may just be the first to notice a breakage.)
Report it, we’ll fix it usually within a day or two, dnf distro-sync, problem solved. While I will certainly admit that I hate GTK and think GNOME shouldn’t exist, that is just me (and a few others who agree on those points), there is certainly no “don’t fix it”, or “intentionally break it” policy. There is “reduce bloat”.
3 Likes
Apologies for offtopic but dang, that sucks. I did have issues getting an app to run in GTK 3 mode so the approach to GTK part makes a lot of sense. I unfortunately depend on a lot of non-flatpak GTK applications so this will be a problem
I personally dislike dealing with all things GTK as well, but it is used by people and used often so I hope there’s something agreed on before you quit but if not, thanks a lot for all your work. Been such a great run with OM so far so I’d hate this happening
Disagreements can always be smoothed out if there is a will.
We as a group always reached consensus finally on everything since the inception to right now.
I hope this one will not be the exception, but I’m confident that won’t happen 
3 Likes
Policies and ideologies are a good thing, but in the end we clash with reality. I don’t use Gnome and I never will, however I believe we all use some GTK apps (Gimp. Gparted, partly Firefox and Thunderbird to name a few) and their value is undeniable.
I hope AngryPenguin can continue its work in OM.
Our disks are getting bigger and bigger, better more space used by GTK libs than fewer collaborators in OM.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.