new stable toolkit branch , which provides a system for building self-contained packages that are not tied to 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. Packages with Flatpak are included in the Fedora repository and maintained in the native GNOME Application Manager.
Key in the Flatpak 1.8 branch:
- Simplified installation in P2P mode (allows you to organize the download of applications and runtime sets through intermediate nodes or drives for systems without a network connection). Dropped support for installing via intermediate hosts on a local network. By default, automatic loading of repositories (sideload) hosted on local USB drives is disabled. To enable intermediate local repositories, configure the repository by creating a symbolic link from /var/lib/flatpak/sideload-repos or
/run/flatpak/sideload-repos. The change made it possible to simplify the internal implementation of the P2P mode and increase its efficiency. - Added optional systemd unit to automatically detect additional repositories on connected external USB drives.
- For applications that have access to the file system, the /lib directory of the host environment is forwarded to /run/host/lib.
- Added new FS access permissions - "host-etc" and "host-os", allowing access to the /etc and /usr system directories.
- To generate more efficient parsing code, GVariant from ostreee is used .
- The configure build crypt provides the ability to build without
libsystemd; - Mounted Journal sockets in read-only mode.
- Added support for exporting directories to document-export.
- Allow direct access to ALSA audio devices for applications that have access to Pulseaudio.
- In the API added "install-authenticator" signal, which can be used by clients to install the authenticators needed to complete a transaction.
- Supported use of timezone data based on /etc/localtime from the host system, resolving timezone related issues in some applications.
- Stopped installing the env.d file from gdm as systemd generators are better at this task.
- The create-usb utility has the export of partial commits enabled by default.
- A sysusers.d file is provided to create the necessary users through systemd.
- Added "--[no-]follow-redirect" option to "flatpak remote-add" and "flatpak modify" commands to disable/enable redirection to another repository.
- Into the system
Added the Spawn API to get the real process ID (PID) of the running application. - All OCI (Open Container Initiative) repositories have been switched to use the flatpak-oci-authenticator authenticator.
- Added "--commit=" option to "flatpak remote-info" and "flatpak update" commands to specify specific version of OCI repositories.
- Added initial delta update support for OCI repositories.
- Added "flatpak upgrade" command, which is an alias for "flatpak update" command.
- Implemented input padding scripts for the fish shell.
Recall that Flatpak makes it possible for application developers to simplify the distribution of their programs that are not included in the regular distribution repositories due to one universal container without generating separate builds for each distribution. For security conscious users, Flatpak allows a questionable application to run in a container, giving access only to the network functions and user files associated with the application. For users who are interested in what's new, Flatpak allows you to install the latest test and stable releases of applications without the need to make changes to the system. For example, Flatpak packages are currently for LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 AD, Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, etc.
To reduce the size of the package, it includes only application-specific dependencies, and the basic system and graphic libraries (Gtk +, Qt, GNOME and KDE libraries, etc.) are designed as pluggable typical runtime environments. The key difference between Flatpak and Snap is that Snap uses the components of the main system environment and isolation based on system call filtering, while Flatpak creates a container separate from the system and operates with large runtime sets, providing typical packages rather than packages as dependencies. system environments (for example, all libraries required for running GNOME or KDE programs).
In addition to the typical system environment (runtime), installed through a special , additional dependencies (bundle) required for the application to work are supplied. In sum, runtime and bundle form the stuffing of the container, while runtime is installed separately and tied to several containers at once, which makes it possible to avoid duplicating system files common to containers. One system can have several different runtimes installed (GNOME, KDE) or several versions of the same runtime (GNOME 3.26, GNOME 3.28). A container with an application as a dependency uses binding only to a specific runtime, without taking into account the individual packages that make up the runtime. All missing items are packaged directly with the application. When the container is formed, the contents of the runtime are mounted as the /usr partition, and the bundle is mounted in the /app directory.
The filling of runtime and application containers is formed using technology , in which the image is atomically updated from a Git-like repository, which allows you to apply version control methods to the components of the distribution (for example, you can quickly roll back the system to a previous state). RPM packages are translated into the OSTree repository using a special layer . Separate installation and updating of packages inside 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 to apply updates incrementally, eliminating the need to completely replace the image with each update.
The generated isolated environment is completely independent of the distribution used and with proper package settings does not have access to files and processes of the user or the main system, cannot directly access the equipment, except for output via DRI, and the network subsystem. Graphic output and input organization using the Wayland protocol or through X11 socket forwarding. Interaction with the external environment is built on the basis of the DBus messaging system and the special Portals API. For insulation interlayer and traditional Linux container virtualization technologies based on the use of cgroups, namespaces (namespaces), Seccomp and SELinux. PulseAudio is used to output sound.
Source: opennet.ru