new stable branch of the toolkit , which provides a system for building self-contained packages that are independent of specific Linux distributions and run in a special container that isolates the application from the rest of the system. Support for running Flatpak packages is provided for Arch Linux, , Debian, Fedora, Gentoo, Mageia, Linux Mint, and Ubuntu. Flatpak packages are included in the Fedora repository and are supported in the GNOME application management program by default.
Key in the Flatpak 1.8 branch:
- The implementation of P2P installation has been simplified (allowing applications and runtime sets to be downloaded through intermediary nodes or storage for systems without network connectivity). Support for installation through intermediate hosts on the local network has been discontinued. Automatic loading of repositories (sideload) placed on local USB drives is disabled by default. To activate intermediate local repositories, the repository should be configured by creating a symbolic link from /var/lib/flatpak/sideload-repos or
/run/flatpak/sideload-repos. Изменение позволило упростить внутреннюю реализацию режима P2P и повысить его эффективность. - An optional systemd unit has been added for automatically detecting additional repositories on connected external USB drives.
- For applications with access to the file system, the /lib directory of the host environment is forwarded to /run/host/lib.
- New file system access privileges have been added — "host-etc" and "host-os", allowing access to system directories /etc and /usr.
- To generate more efficient code for parsing GVariant files from ostree, .
- In the build script configure, the ability to build without
libsystemd; - Socket mounting for Journal is ensured in read-only mode.
- Support for exporting directories has been added to document-export.
- Direct access to ALSA sound devices is allowed for applications with access to Pulseaudio.
- In the API a signal "install-authenticator" has been added, which can be used by clients to install authenticators required for completing transactions.
- Timezone data based on /etc/localtime from the host system is now used, addressing timezone-related issues in some applications.
- Installation of the env.d file from gdm has been discontinued, as systemd generators handle this task better.
- In the create-usb utility, export of partial commits is enabled by default.
- Delivery of the sysusers.d file for creating necessary users through systemd is ensured.
- The commands ‘flatpak remote-add’ and ‘flatpak modify’ have been enhanced with the ‘—[no-]follow-redirect’ option to forbid/allow redirection to another repository.
- The system
now includes the API Spawn to retrieve the real process identifier (PID) of the launched application. - All OCI (Open Container Initiative) repositories have transitioned to using the flatpak-oci-authenticator.
- The ‘flatpak remote-info’ and ‘flatpak update’ commands have a new ‘—commit=’ option to specify a particular version of OCI repositories.
- Initial support for delta updates for OCI repositories has been added.
- The command ‘flatpak upgrade’ has been introduced as an alias for the ‘flatpak update’ command.
- Input completion scripts for the fish shell have been implemented.
Let us remember that Flatpak provides developers with the opportunity to simplify the distribution of their applications, which are not included in the standard distribution repositories, due to a single universal container without creating separate builds for each distribution. For security-conscious users, Flatpak allows running potentially suspicious applications in a container, granting access only to network functions and user files related to the application. For users interested in new releases, Flatpak enables the installation of the latest testing and stable versions of applications without needing to modify the system. For example, Flatpak packages are currently for LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, etc.
To reduce the package size, it only includes application-specific dependencies, while core system and graphical libraries (Gtk+, Qt, GNOME and KDE libraries, etc.) are organized as plug-in standard runtime environments. The key difference between Flatpak and Snap is that Snap uses the components of the host system's environment and isolation based on system call filtering, whereas Flatpak creates a separate container from the host system and operates large runtime sets, providing standard system environments (for example, all libraries needed for GNOME or KDE applications) as dependencies instead of packages.
In addition to the standard system environment (runtime) installed via a special , additional dependencies (bundle) required for application operation are supplied. Together, the runtime and bundle form the contents of the container, with the runtime being installed separately and linked to several containers at once, thus avoiding duplication of shared system files among containers. Multiple different runtimes (GNOME, KDE) or several versions of one runtime (GNOME 3.26, GNOME 3.28) can be installed on one system. A container with the application as a dependency links only to a specific runtime, disregarding the individual packages that make up the runtime. All missing components are bundled directly with the application. When creating a container, the contents of the runtime are mounted as the partition /usr, while the bundle is mounted in the /app directory.
The contents of the runtime and application containers are formed using the technology , in which the image is atomically updated from a Git-like repository, allowing version control methods to be applied to distribution components (for example, the system can be quickly rolled back to a previous state). RPM packages are translated into the OSTree repository using a special layer . Separate installation and updating of packages within the working environment is not supported; the system is updated not at the level of individual components but as a whole, atomically changing its state. Tools are provided for the incremental application of updates, alleviating the need for complete image replacement with each update.
The isolated environment that is formed is completely independent of the used distribution and, with proper package settings, does not have access to user files or processes from the main system, cannot directly interact with the hardware except for output via DRI, and the network subsystem. Output of graphics and input organization using the Wayland protocol or through X11 socket forwarding. Interaction with the external environment is based on the DBus messaging system and a special API Portals. For isolation is used and the traditional container virtualization technologies for Linux, based on the use of cgroups, namespaces, Seccomp, and SELinux. PulseAudio is used for sound output.
Source: opennet.ru
