[FEATURE REQUEST] Flatpak/Appimage Release

[repires]

Feature request: Could you provide a Flatpak (and/or restore the AppImage) so LinuxToys can run on atomic/immutable systems without rpm-ostree layering? This would greatly benefit Fedora Workstation (rpm-ostree variant) and uBlue images like Bluefin/Bazzite/Aurora.

Why Flatpak/AppImage:

• Avoids layering on ostree-based systems; simpler install/update workflow via Flathub or a GitHub Releases artifact.
• Sandboxed runtime with portals for GTK/zenity and Python bindings; fewer host dependencies to manage.
• Works uniformly across Fedora Atomic, Silverblue/Bluefin, and traditional distros.

Notes that may help:

• Flatpak: Package the GTK/zenity Python app with org.gnome.Platform runtime (e.g., 46), bundle Python deps, expose needed permissions (network, file chooser). A minimal manifest (flatpak-builder) and a nightly CI job could publish to a Flatpak repo or submit to Flathub.
• AppImage: Ship a self-contained build with python, gtk, and gobject introspection bundled; keep the existing CLI mode working with LT_MANIFEST=1.

Happy to help test on Bluefin and Bazzite if a preview build is published.

[psygreg]

It's not possible for two reasons.

First, because LinuxToys is not - and will never be - compatible with all Linux operating systems. Many features require systemd to work; we can't always account for differences in repositories for certain distros (hence why it's not compatible with OpenMandriva to this day even though it should be on paper); and for a few others like Gentoo and NixOS this tool simply doesn't make any sense, since it would break the basic premises of those, defeating the entire purpose someone would have to use them.

Second, both AppImages and Flatpaks have limitations caused by userspace that would severely limit the ability of the application to perform its tasks, and these will most likely never be resolved because it's the philosophy of these packaging formats. We can't use packaging designed to prevent changing the underlying operating system for an app which its entire purpose is to make changes to the operating system.

On ease of installation, there's the install.sh to get installing and updating LT two clicks away - or one command away if you opt for the single-liner in the website, for any supported Linux distribution.

[psygreg]

On a side note, I personally use Bluefin with LinuxToys and its optimizations layered, so I'd be the first to find out if anything goes south to fix it.

[repires]

I now understand the technical limitations you’ve outlined regarding Flatpak/AppImage sandboxing preventing system-level changes that LinuxToys requires.
However, I wanted to suggest an alternative that aligns with the Bluefin/uBlue philosophy of minimizing rpm-ostree layering: Have you considered packaging LinuxToys as a Homebrew formula in a custom tap?
The uBlue project maintains their own Homebrew tap at https://github.com/ublue-os/homebrew-tap specifically for this use case. Homebrew on Linux:
• Installs to userspace ( ~/.linuxbrew  or  /home/linuxbrew ) avoiding ostree layers
• Can still execute system-level operations through sudo when needed
• Provides familiar install/update workflow ( brew install ,  brew upgrade )
• Works across all ublue images (Bluefin, Bazzite, Aurora) and traditional distros
• Avoids the philosophical conflicts with containerized packaging formats
A Homebrew formula would give users the benefits of easy installation/updates without the layering overhead, while still maintaining LinuxToys’ ability to make system changes.
Happy to help test if you decide to explore this approach.