Module-specific packages are listed as required dependencies

[CelDaemon]

I recently installed waybar, and noticed that multiple new desktop entries appeared in my launcher.

Most of these don't matter, but xgps stood out to me as I do not have a GPS in my laptop.

I understand these dependencies are required to use some of the modules provided by waybar, but they are not necessary for the core program to work when these modules are not in use.

I'd like to be able to uninstall these packages without making pacman ignore dependency checks, would it be possible to mark these dependencies are optional?

[CelDaemon]

The added tags are incorrect, this issue affects all modules that depend on external packages.

[Vescrity]

Mark dependencies optional or not is the job of the package's maintainer of your distribution.

You can make a package by yourself to "provide" gpsd, and then you can uninstall it.

And then you'll find that waybar refuse to launch as it needs libgps.so.31 even if you don't use gps module.

So I uncompressed the gpsd package and then copy the libgps.so.31 to /usr/lib/ , it can work now.

But you'll have a file won't be tracked by pacman, so:

You can make a package by yourself, "provide" gpsd (write that in PKGBUILD), and put libgps.so.31 to usr/lib, then install it.

However, you may need to update it manually by yourself when gpsd upgrade with a new .so.* filename.

[Bootjewolf]

Isn't it a possibility to dynamically load these libraries only when they are included in the current configuration. Or would this require a major rewrite in the way modules and their libraries are linked?

[CelDaemon]

My apologies, I didn't realise it was required to actually run. I had made this issue as I thought the AUR package was handled by the actual waybar project.

Aside from that, is there a reason gpsd isn't loaded at runtime when the module is enabled? The normal gpsd package causes clutter in some launchers, which seems silly when my device doesn't support it in the first place.

[qbe]

It seems to me that at least some of the modules requiring bigger or less common dependencies should be split from the waybar binary into some form of dynamically loadable module.

this would let maintainers declare these module-specific dependencies as "optional", or even split the modules into seperate packages.

since there is already a cffi interface this should afaik at least be possible. All compiled modules derived from the waybar source could (should ?) reside in /usr/lib{arch}/waybar/ , and should be auto-loaded if present in the configuration, without specifying their path as you would for a custom cffi module.

The size overhead of cutting the source code apart like this should be relatively small, compared to the size overhead of having unwanted GPS GUI applications installed (yes, at least on Arch xgps is part of the gpsd package).

I might have the time to try refactoring one module myself, but if anyone (more) familiar with the source sees bigger problems with this approach I would like to know.

Edit: it might be easier to use POSIX dynamic loading (dlfcn.h) for currently built-in modules.

[Samq64]

I also thought this was an Arch packaging issue. While it would be nice if most module-specific dependencies could be optional I mostly just care about gpsd.

[hunkyburrito]

The gpsd dependencies are only required if you build waybar with the gps feature enabled.

The problem is that the Arch package uses --auto-features=enabled which turns on all features of waybar when building. The funny thing is they already disable cava support using -Dcava=disabled presumably because the maintainer feels it was unnecessary to include the cava dependencies.

The waybar-git package on the AUR disables both cava and gpsd by default, but allows you to build them with environment variables (__with_cava=true and __with_gpsd=true).

[qbe]

The gpsd dependencies are only required if you build waybar with the gps feature enabled.

Unfortunately, as far as I'm concerned, most users don't build their own packages.

The problem is that the Arch package uses --auto-features=enabled which turns on all features of waybar when building.

I think the Arch approach of "maximum functionality" is relatively valid, but runs into a problem when software has a bunch of compiletime feature-flags that require "large" (meaning here "may include .desktop files") dependencies. Which results in Arch users having the choice of the AUR package, or the non-AUR package that depends on gpsd et al. There is relatively little the Arch maintainer can do here, except possibly creating multiple compiled versions of the package with different compile-time options and therefore other sets of dependencies.

The funny thing is they already disable cava support using -Dcava=disabled presumably because the maintainer feels it was unnecessary to include the cava dependencies.

This could also be improved with dynamic loading. Working on it.

[qbe]

current status: In the middle of implementing a proof of concept for dlfcn.h-based dynamic loading of the gps module. Currently stuck at the reap_mtx mutex being defined in main.cpp but used as external symbol in all modules (via AModule.hpp -> util/command.hpp). Currently reluctant to add a *reap_mtx to the AModule constructor, but this seems like the only real option.

[qbe]

update: it compiles, but since I don't have a GPS receiver I can't determine if the GPS module works fully (after all, i started all of this to be able to get rid of the gpsd dependency of the arch package while retaining the functionality for those that want it).

With a running GPS daemon I can get the gps module to load from a waybar-module-gps.so file (an appropriate LD_LIBRARY_PATH is needed), and it seems to connect to gpsd.

In order to test this further, I will now try to move a module that I can test more easily (probably the mpris module) to dlfcn.h based dynamic loading as well.

[qbe]

I picked the cava module instead, which means I could also confirm that if the dynamic loader cannot find libcava (or libgps) the loading of the cava (or gps) module will fail gracefully.