🥇Wydanie systemu samodzielnych pakietów Flatpak 1.18.0

Po półtora roku prac rozwojowych opublikowano nową stabilną wersję narzędzia Flatpak 1.18, która oferuje system do budowy samowystarczalnych pakietów, niezwiązanych z konkretnymi dystrybucjami Linux i uruchamianych w specjalnym kontenerze, izolującym aplikację od reszty systemu. Obsługa uruchamiania pakietów Flatpak jest zapewniona dla Fedora, CentOS, Debian, Arch Linux, Gentoo, Linux Mint, Alt Linux i Ubuntu. Pakiety Flatpak są dostępne w repozytorium Fedora i są wspierane przez standardowe programy zarządzania aplikacjami GNOME i KDE.

Kluczowe nowości w wersji Flatpak 1.18:

Zaimplementowano wsparcie dla warunkowych uprawnień (conditional permission), które pozwalają przy żądaniu uprawnień sprawdzić obecność określonych możliwości w systemie lub runtime. Na przykład, zamiast używać „—device=all” do uzyskania dostępu do urządzenia wejściowego, można zażądać uprawnienia „—device-if=all:!has-input-device —device=input”, które przyzna dostęp tylko do urządzeń wejściowych lub wróci do dostępu do wszystkich urządzeń, jeśli selektywne przyznawanie dostępu nie jest obsługiwane w runtime. Podobnie można zażądać dostępu do urządzeń USB („has-usb-device” i „has-usb-portal”) lub współdzielonych podsystemów.
Zezwolono na dostęp do urządzenia /dev/ntsync w celu korzystania z
modułu jądra NTSYNC, który implementuje zestaw prymitywów synchronizacji stosowanych w jądrze Windows NT, znacznie zwiększających wydajność gier Windows uruchamianych za pomocą Wine.
Dla GPU Intel Xe włączono wsparcie dla API VA-API do sprzętowego przyspieszania dekodowania wideo.
Zrealizowano możliwość dostępu do urządzenia /dev/kfd (Kernel Fusion Driver) przy użyciu uprawnień przyznanych dla urządzeń DRI. Sterownik kfd implementuje interfejs do bezpośredniego wykonywania obliczeń na GPU AMD z aplikacji korzystających z AMD ROCm, HIP i OpenCL.
Dodano wsparcie do wykorzystania opcji wiersza poleceń do przekazywania dostępu do katalogów w izolowanych aplikacjach.
Dodano wsparcie dla katalogu „preinstall.d”, definiującego listę aplikacji Flatpak do preinstalacji (w celu uwzględnienia aplikacji Flatpak w systemie operacyjnym).
Umożliwiono bezpośrednią instalację aplikacji z obrazów kontenerów w formacie OCI, które mogą być ładowane z własnych repozytoriów OCI i lokalnych archiwów.
Do polecenia „flatpak install —from” dodano wsparcie dla URI „flatpak+https://”.
Do zespołu «flatpak run» dodano opcję «—clear-env», aby wyczyścić zmienne środowiskowe przed uruchomieniem aplikacji.
Umożliwiono eksport katalogu głównego hosta środowiska do izolowanego środowiska aplikacji z dostępem poprzez katalog /run/host/root.
Dodano możliwość wyświetlania wyników wykonania poleceń w formacie JSON.
Wzmocniono izolację środowiska budowania — polecenie «flatpak build» nie zapewnia teraz domyślnie dostępu do hosta.
Dodano polecenie «reinstall» do ponownej instalacji zależności (bundle).
Domyślne ustawienia D-Bus przeniesiono z katalogu /etc do /usr.
Skrócono czas uruchamiania przy użyciu interpretera poleceń fish.
W libflatpak dodano funkcję do uzyskiwania informacji o czasie utworzenia konfiguracji, co pozwala aplikacjom, takim jak GNOME Software, określać, że dane z pamięci podręcznej wymagają aktualizacji.
Usunięto opcję budowania http_backend, a zamiast libsoup2 do ładowania przez HTTP/HTTPS wykorzystano bibliotekę libcurl.
Domyślnie włączono użycie sekwencji ucieczki do wskazywania postępu operacji.
Zezwolono na przekazywanie uprawnień do urządzeń do zagnieżdżonych środowisk sandbox stworzonych za pośrednictwem portali Flatpak.
Dla aplikacji dostarczanych w postaci obrazów OCI wprowadzono mechanizm «extra-data», który umożliwia na przykład organizację odtwarzania wideo h.265 w pakietach Flatpak na systemie Fedora Linux.
Dodano wsparcie dla kompresji zależności (OCI bundle) z wykorzystaniem algorytmu zstd, który skuteczniej kompresuje dane. Domyślnie do kompresji nadal używany jest gzip, zapewniający maksymalną zgodność.

Flatpak upraszcza dystrybucję oprogramowania, które nie znajduje się w standardowych repozytoriach dystrybucji, dzięki przygotowaniu jednego uniwersalnego kontenera, uwalniającego programistów od potrzeby tworzenia odrębnych kompilacji dla każdej dystrybucji. Użytkownikom dbającym o bezpieczeństwo, Flatpak daje możliwość uruchamiania podejrzanych aplikacji w kontenerze, zapewniając selektywny dostęp tylko do potrzebnych funkcji sieciowych i plików użytkownika. Użytkownikom zainteresowanym nowościami, Flatpak umożliwia instalację najnowszych wersji testowych i stabilnych aplikacji bez konieczności wprowadzania zmian w systemie. Na przykład, pakiety Flatpak są dostępne dla LibreOffice, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Telegram Desktop, Android Studio itd.

Aby zmniejszyć rozmiar, do pakietu dołączane są jedynie specyficzne dla aplikacji zależności. Podstawowe biblioteki systemowe i graficzne (GTK, Qt, biblioteki GNOME i KDE itd.) są dostarczane w postaci wtyczkowych standardowych środowisk uruchomieniowych. Kluczowa różnica między Flatpak a Snap polega na tym, że Snap wykorzystuje komponenty środowiska głównego systemu i izolację opartą na filtrowaniu wywołań systemowych, podczas gdy Flatpak tworzy kontener odseparowany od systemu i operuje dużymi zbiorami środowisk uruchomieniowych, dostarczając jako zależności nie pakiety, a standardowe środowiska systemowe (na przykład wszystkie biblioteki potrzebne do pracy programów GNOME lub KDE).

Oprócz standardowego środowiska systemowego (runtime), instalowanego przez specjalne repozytorium, dostarczane są dodatkowe zależności (bundle), wymagane do działania aplikacji. W sumie „runtime” i „bundle” tworzą zawartość kontenera, przy czym „runtime” instalowane jest oddzielnie i może być przypisane do kilku kontenerów, co pozwala uniknąć duplikacji wspólnych dla kontenerów plików systemowych.

W jednej systemie może być zainstalowanych kilka różnych „runtime” (GNOME, KDE) lub kilka wersji jednego „runtime” (GNOME 50, GNOME 49). Kontener z aplikacją jako zależnością używa powiązania tylko z określonym „runtime”, bez uwzględnienia poszczególnych pakietów, które tworzą wybrany „runtime”. Wszystkie brakujące elementy są pakowane bezpośrednio razem z aplikacją. Podczas tworzenia kontenera zawartość „runtime” jest montowana jako część /usr, a „bundle” montowane jest w katalogu /app.

Skład „runtime” i kontenerów aplikacji jest tworzony z użyciem technologii OSTree, w której obraz atomowo aktualizuje się z magazynu przypominającego Git, co pozwala stosować metody kontroli wersji do komponentów dystrybucji (np. można szybko przywrócić system do poprzedniego stanu). Pakiety RPM są tłumaczone do repozytorium OSTree przy pomocy warstwy rpm-ostree.

Wyborcza instalacja i aktualizacja pakietów wewnątrz środowiska roboczego nie jest obsługiwana — system aktualizuje się nie na poziomie pojedynczych komponentów, a w całości, atomowo zmieniając swoje stany. Zapewnione są narzędzia do inkrementalnego stosowania aktualizacji, eliminujące potrzebę pełnej wymiany obrazu przy każdej aktualizacji.

Tworzone izolowane środowisko nie zależy od używanej dystrybucji i przy odpowiednich ustawieniach pakietu nie ma dostępu do plików i procesów użytkownika lub głównego systemu, a także nie może bezpośrednio komunikować się z sprzętem, z wyjątkiem wyjścia przez DRI. Wyjście grafiki i organizacja wejścia są realizowane za pomocą protokołu Wayland lub poprzez przekazywanie gniazd X11. Interakcja z zewnętrznym środowiskiem odbywa się przez system wymiany wiadomości DBus i specjalne API Portals.

Do izolacji używana jest warstwa Bubblewrap oraz tradycyjne technologie wirtualizacji kontenerów w systemie Linux, oparte na użyciu cgroups, przestrzeni nazw (namespaces), Seccomp i SELinux. Podczas tworzenia pakietu izolacja może być wyłączona, z czego korzystają deweloperzy niektórych pakietów, aby uzyskać pełny dostęp do systemu plików i wszystkich urządzeń w systemie.

Źródło: opennet.ru