← Older edit
Newer edit →
Trim the Beard
1,752 bytes added
10 months ago
Support for AppImage/Flatpak/etc
I know i am monotony. And i know @drobins You worked on this. But for my perspective is very importand
=== Support for AppImage/Flatpak/etc ===
Sometimes, upstream projects package applications, and nowadays many of them do a "good enough" job. The consequence is that Funtoo can rely more on application developers to create packages. (We are already doing this with firefox-bin, google-chrome, zoom-bin, etc.)
The three most common formats seem to be AppImage, Flatpak, and Snap. AppImage works out of the box (because an AppImage package is an executable wrapper around an ISO 9660 fs), but desktop integration is a bit of a hassle. appimaged is a good start, but it is not complete. Maybe some ebuild and metatools magic could help. I personally have LibreOffice and Krita running via AppImages installed to /usr/local/bin.
Some Funtoo'ers have installed Flatpak from an official Flatpak overlay with a little bit of tweaking. Flatpak is supposed to integrate well with the GNOME desktop (and probably others). I personally have yet to try Flatpak.
Then there are a few projects that still use more traditional methods that ultimately involve writing to a self-contained directory on the filesystem: tarballs extracted to /opt, git repos, etc: texlive, plan9port, Pale Moon, upstream Mozilla Firefox/Thunderbird tarballs. Some of these are already transformed into native packages with ebuild and metatools magic. Some more of them can be.
Advantages of utilizing upstream pre-compiled packaging:
* Less work for Funtoo developers.
* Installations of applications can be officially condoned by upstream app developers.
* Many useful one-off utilities could be easily installed (see Flatpak hub) and updated without bothering Funtoo developers to package them.
* Processor optimizations (e.g. avx, avx2) are not used.
Retrieved from "
Find your CPU
Report a Bug
Wiki Editing Guidelines