[Linux] `libayatana-appindicator` troublesome

[arran4]

Rewritten with explicit separation of problems, causes, and solutions.

---

Summary

The library libayatana-appindicator, currently used for Linux support, creates multiple issues for Linux distributions and downstream users. These issues fall into three main categories: packaging constraints, binary compatibility problems, and licensing risks.

In practice, these issues arise because the library is being used where a simple D-Bus implementation would suffice, and the current dependency chain introduces unnecessary complexity.

---

Issues

1. Packaging problems on Linux distributions

Using libayatana-appindicator is difficult for many Linux distributions due to their packaging policies and Flutter’s installation model.

Cause

Most distributions prohibit network access during package builds. Examples:

• Gentoo packaging rules:
  https://devmanual.gentoo.org/ebuild-writing/functions/src_test/index.html#tests-that-require-network-or-service-access

• Debian policy:
  https://www.debian.org/doc/debian-policy/ch-source.html

Required targets must not attempt network access during build.

However Flutter itself often expects:

• installation in writable directories
• downloading artifacts during build
• execution outside restricted environments

Flutter explicitly documents issues when installed in restricted locations:
https://docs.flutter.dev/install/troubleshoot#flutter-in-special-folders

Result

Package maintainers are forced to rely on prebuilt binaries rather than building from source.

---

2. Binary compatibility issues

Using prebuilt binaries introduces compatibility problems with system libraries.

Cause

The libayatana-appindicator libraries installed by distributions can vary in:

• file names
• ABI versions
• installation paths

Examples from typical installations:

/usr/lib64/libayatana-appindicator3.so
/usr/lib64/libayatana-appindicator3.so.1
/usr/lib64/libayatana-appindicator3.so.1.0.0
/usr/lib64/libayatana-ido3-0.4.so
/usr/lib64/libayatana-ido3-0.4.so.0
/usr/lib64/libayatana-ido3-0.4.so.0.0.0
/usr/lib64/libayatana-indicator3.so
/usr/lib64/libayatana-indicator3.so.7
/usr/lib64/libayatana-indicator3.so.7.0.0

Prebuilt binaries may:

• expect a different version of these libraries
• expect them in different paths
• link against incompatible builds

Additional complication

The library ecosystem has been forked and renamed multiple times, meaning different distributions may ship different implementations.

Examples:

• https://github.com/AyatanaIndicators/libayatana-appindicator
• https://github.com/AyatanaIndicators/libayatana-appindicator-glib

Distribution renames and compatibility issues:

• https://www.reddit.com/r/debian/comments/pn1oia/what_happened_to_libappindicator31_in_debian_11/
• https://unix.stackexchange.com/questions/701050/how-do-i-download-libappindicator1
• Debian 11 (testing) and libindicator (libayatana-indicator instead?) signalapp/Signal-Desktop#4866
• https://builds.openbuilds.com/threads/libappindicator3-1.18899/

---

3. GPL licensing risk

A major issue is the license of the library.

libayatana-appindicator is licensed under GPL-3.0:
https://github.com/AyatanaIndicators/libayatana-appindicator/blob/main/COPYING

Cause

If a project links against a GPL library (including via FFI), the GPL's copyleft terms may apply to the entire program.

This can require the entire application to be distributed under GPL-compatible terms.

Result

This introduces a licensing contamination risk for downstream users, particularly those who wish to distribute closed-source software.

---

Root cause

After investigation, libayatana-appindicator does not provide complex functionality.

It is primarily an implementation of the StatusNotifierItem specification:

https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/

This specification simply defines a D-Bus interface for system tray indicators.

---

Alternative approach

Instead of depending on a GPL C library, the functionality can be implemented directly in Dart.

D-Bus access is already available via:

https://pub.dev/packages/dbus

License: MPL

---

Existing work

There is already a Dart implementation of the specification:

Author:
https://github.com/robert-ancell

Repository:
https://github.com/canonical/xdg_status_notifier_item.dart

Mirror:
https://github.com/robert-ancell/xdg_status_notifier_item.dart

This implementation does not yet include all required features.

I am currently working on extending this functionality here:

https://github.com/arran4/dart_xdg_status_notifier_item

My goal is to eventually contribute support to:

https://github.com/leanflutter/tray_manager

---

Recommended solutions

Short-term options

1. Continue using libayatana-appindicator, accepting:

   • Linux packaging difficulties
   • binary compatibility problems
   • GPL licensing implications

2. Replace the dependency with a direct Dart implementation of the StatusNotifierItem specification.

Preferred long-term solution

Implement the StatusNotifierItem protocol directly in Dart using the dbus package.

This approach would:

• remove the GPL dependency
• eliminate binary compatibility issues
• simplify Linux packaging
• avoid distribution-specific library differences

---

Additional note

I initially attempted to port the original C implementation here:

https://github.com/arran4/dart-libayatana-appindicator-glib

However after completing the port I discovered the GPL-3.0 license.

Given the number of contributors:

https://github.com/arran4/dart-libayatana-appindicator-glib/blob/main/AUTHORS

relicensing would realistically be impossible.

---

Summary

1. libayatana-appindicator causes packaging problems for Linux distributions.
2. Prebuilt binaries introduce ABI and library path compatibility issues.
3. The GPL license creates licensing risk for downstream users.
4. The library itself mainly implements the StatusNotifierItem D-Bus specification.
5. A pure Dart implementation using dbus avoids these problems.

For that reason I wanted to raise awareness of the issue here and suggest considering a replacement implementation.

[lijy91]

Thank you for your feedback. I've always hoped that native APIs would avoid introducing third-party dependencies as much as possible. I will be migrating it to the D-Bus implementation and removing this library.

[arran4]

I found when porting: https://github.com/canonical/xdg_status_notifier_item.dart to: https://github.com/arran4/dart_xdg_status_notifier_item that the spec was more of an "idea" than something people follow. So KDE does things differently to Gnome.

Which platforms do you test on? (I'm on KDE.)