Jak krok po kroku utworzyć pakiet AppImage w systemie GNU/Linux

Jeśli na co dzień poruszasz się po świecie GNU/Linux, prędzej czy później natkniesz się na słynne pliki Pliki .AppImage. Warto dowiedzieć się, czym one są, jak z nich korzystać i jak krok po kroku tworzyć własne pliki.To nie jest po prostu „kolejny format”: za AppImage stoi jasna filozofia przenośności, mniejsza liczba zepsutych zależności i mniej problemów z wersjami bibliotek.

Co więcej, gdy zaczniesz kompilować własne programy lub pakować aplikacje dla innych, szybko odkryjesz, że utrzymanie .deb, .rpm i inne formaty dla każdej dystrybucji to prawdziwy ból głowyTo właśnie tam AppImage wraz z narzędziami takimi jak linuxdeploy, AppImageKit i Pkg2appimageStaje się bardzo skuteczną alternatywą dla dystrybucji oprogramowania desktopowego w niemal każdej nowoczesnej dystrybucji.

Czym właściwie jest pakiet AppImage i dlaczego warto go mieć?

Plik AppImage to w zasadzie: samodzielny plik wykonywalny dla GNU/Linux, który zawiera aplikację i wszystkie jej zależności Niezbędne pliki (biblioteki dynamiczne, zasoby, ikony itp.) są kompresowane do jednego obrazu. Zamiast instalować się jak tradycyjny pakiet dystrybuujący pliki w systemie, zachowuje się on podobnie:

• „Przenośny” plik .exe w Windows, który możesz mieć na dysku USB i uruchamiać gdziekolwiek chcesz.
• Plik .dmg w systemie macOS, który zawiera aplikację gotową do użycia bez konieczności klasycznej instalacji.

Po uruchomieniu AppImage system montuje się wewnętrznie skompresowany obraz ISO w trybie tylko do odczytuPrzygotowuje środowisko i uruchamia program w jego wnętrzu. Po zamknięciu aplikacji tymczasowe montowanie znika. Nie ma faktycznej „instalacji”, jak w przypadku pakietów DEB czy RPM. Jeśli usuniesz plik .AppImage, usuniesz program. bez pozostawiania śladów (oprócz plików konfiguracyjnych lub integracyjnych, jeśli zostały wygenerowane).

Ten format mieści się w ramach tego, co jest znane jako „Uniwersalne aplikacje dla GNU/Linux”wraz z innymi systemami takimi jak Flatpak i Snap (i, w mniejszym stopniu, propozycje takie jak OrbitalApps). Chodzi o to, że deweloper Wystarczy spakować go raz, a użytkownik będzie mógł uruchomić go na dowolnej współczesnej dystrybucji GNU/Linux.unikając piekła związanego z utrzymywaniem konkretnych wersji dla Debiana, Ubuntu, Fedory, openSUSE itp.

Wśród najciekawszych funkcji AppImage znajduje się kilka, które odróżniają go od tradycyjnych pakietów: przenośny, nie wymaga uprawnień korzeń do uruchomienia i nie dotyka bibliotek systemowych ani preferencji globalnychInnymi słowy, możesz pobrać AppImage, nadać mu uprawnienia do wykonywania i uruchomić w środowisku Live. USB, w stabilnym systemie ze starymi repozytoriami lub w dość niedawnej wersji ciągłej bez konieczności kompilacji czegokolwiek lub rozwiązywania zależności.

Zalety i wady formatu AppImage w porównaniu do klasycznych pakietów

Zanim zagłębisz się w proces tworzenia, ważne jest, aby mieć jasność co do tego, co oferuje ten format i jakie są jego wady, zwłaszcza jeśli się na to decydujesz czy dystrybuować aplikację jako AppImage, jako pakiet natywny czy jako oba..

Z pozytywnej strony, AppImage to Samodzielny plik binarny z rozszerzeniem .AppImage, który działa praktycznie na każdej dystrybucji bez konieczności instalowania czegokolwiek dodatkowego (poza FUSE w większości przypadków). Oznacza to, że:

• Nie jesteś zależny od bibliotek systemowychBiblioteki potrzebne Twojemu programowi znajdują się w samym pliku.
• Nie potrzebujesz uprawnień superużytkownika aby korzystać z aplikacji, ponieważ pliki nie są kopiowane do ścieżek systemowych, takich jak /usr lub /etc.
• Jest niezwykle przenośnyMożesz zapisać wiele obrazów AppImage na dysku USB i używać ich na różnych komputerach i dystrybucjach bez żadnych problemów.
• Eliminują wiele konfliktów zależności, typowe dla sytuacji „Chcę użyć nowej wersji programu X na starej stabilnej dystrybucji”.
• Pozwól użyj najnowszych aplikacji w LTS lub bardzo konserwatywnych dystrybucjach (Debian stable, Ubuntu LTS itd.) bez uszkadzania systemu.
• Są idealne do testowanie oprogramowania bez narażania bezpieczeństwaszczególnie jeśli połączysz je z sandboxingiem (na przykład Firejail).

To jednak nie wszystkie zalety. AppImage ma również swoje słabości w porównaniu z tradycyjnymi repozytoriami każdej dystrybucji. Na przykład aplikacje uwzględnij wszystkie swoje bibliotekiostateczny rozmiar to zwykle większy niż pakiet natywny który ponownie wykorzystuje biblioteki współdzielone już obecne w systemie. Ponadto:

• Integracja pulpitu nie zawsze jest idealnaDostępne są narzędzia takie jak appimaged lub AppImageLauncher, które usprawniają tę funkcję, ale w wielu przypadkach wymagana jest praca ręczna (menu, skojarzenia plików itp.).
• Te Aplikacje AppImage zwykle uruchamiają się nieco dłużej.Ponieważ skompresowany obraz musi zostać najpierw zamontowany, po otwarciu działa on normalnie.
• Automatyczne aktualizacje nie zawsze są dobrze wdrażaneDostępne są narzędzia takie jak AppImageUpdate czy obsługa zsync, ale w przypadku większości oprogramowania nadal konieczne jest pobranie nowego pliku AppImage i ręczna wymiana starego.
• El Katalog aplikacji w formacie AppImage nie jest zbyt obszerny. podobnie jak w przypadku oficjalnych repozytoriów głównych dystrybucji, choć coraz częściej obejmuje ona również ważne projekty (Krita, GIMP, Kdenlive, LibreOffice, itp.).
• Ogólnie uważa się, że Pakiety przechowywane w oficjalnych repozytoriach zazwyczaj przechodzą dodatkową kontrolę bezpieczeństwa Jeśli chodzi o pliki binarne pobrane bezpośrednio ze strony internetowej, musimy zachować ostrożność w kwestii pochodzenia wykorzystywanych przez nas obrazów AppImages.

Mimo to w wielu scenariuszach AppImage jest bardzo praktycznym rozwiązaniem: na przykład, Uruchamianie aplikacji, które nie znajdują się w repozytoriach dystrybucji, pomijanie absurdalnych zależności lub korzystanie z bieżącego oprogramowania na starych maszynachZ punktu widzenia programisty, spakowanie pojedynczego AppImage dla wszystkich dystrybucji oszczędza mnóstwo pracy.

Jak AppImage jest zbudowany wewnętrznie: katalog AppDir

Większość narzędzi generujących obrazy aplikacji działa w oparciu o podstawową koncepcję: AppDir, katalog o strukturze rozpoznawanej przez ekosystem AppImageWszystko, co znajdzie się w pliku .AppImage, jest najpierw organizowane w drzewie katalogów.

W swojej minimalnej formie AppDir wymaga co najmniej trzy pliki kluczowe w Twoim katalogu głównym:

• Apprun: ręka scenariusz lub plik wykonywalny, który uruchamia się, gdy to robisz ./MiPrograma.AppImageJest on odpowiedzialny za przygotowanie środowiska (PATH, LD_LIBRARY_PATH itd.) i uruchomienie faktycznej aplikacji.
• Plik .desktop: zawiera metadane aplikacji (nazwę, komentarz, kategorie, ikonę, polecenie wykonania…) zgodne ze specyfikacją Desktop Entry freedesktop.org.
• Ikona (zwykle .png lub .svg): używany zarówno do wyświetlania ikony pliku AppImage w eksploratorach plików, jak i w zintegrowanych z systemem programach uruchamiających aplikacje.

Poza tą minimalną bazą, AppDir zazwyczaj stosuje strukturę podobną do struktury konwencjonalnego systemu GNU/Linux, przestrzegając standardu FHS (Filesystem Hierarchy Standard). Utwórz podkatalogi, takie jak ./usr/bin, ./usr/lib lub ./usr/shareUmieść w nich następujące rzeczy:

• En usr/bin/, główny plik binarny Twojej aplikacji (na przykład, hello-world, Rectball, nvimItp.).
• En usr/lib/, biblioteki współdzielone (.so), których potrzebuje Twój program i których nie powinieneś zakładać, że użytkownik zainstalował w swoim systemie.
• En usr/share/aplikacje/, plik .pulpit który opisuje aplikację.
• En usr/share/ikony/hicolor/ (i podobne trasy), ikony aplikacji w różnych rozmiarach.

Istotne jest, aby plik wykonywalny był niezależnie od lokalizacji w systemie plikówJeżeli Twój program zakłada ścieżki absolutne w ten sposób: /usr/bin/miapp o /usr/share/miappBędą problemy z uruchomieniem AppImage, ponieważ w czasie wykonywania jest on montowany w innej lokalizacji tymczasowej. Prawidłowe podejście to praca z trasami względnymi lub budować je dynamicznie z rzeczywistej ścieżki pliku binarnego lub skryptu AppRun.

Bardziej kompletna lista AppDir może wyglądać następująco:

$ ls -l
AppRun
miaplicacion.desktop
miaplicacion.svg
usr/

$ ls -R usr
usr/bin/miaplicacion
usr/lib/…
usr/share/applications/miaplicacion.desktop
usr/share/icons/hicolor/…

Gdy już masz taką strukturę, narzędzia takie jak linuxdeploy lub appimagetool (z AppImageKit) Będą oni odpowiedzialni za konwersję AppDir do końcowego pliku .AppImage.

Plik .desktop i podstawowa integracja pulpitu

Plik .desktop jest kluczowym komponentem zarówno dla AppImage, jak i integracji dowolnej aplikacji desktopowej z systemem GNU/Linux. Jest to prosty plik tekstowy z odpowiednim formatowaniem. Wpis na pulpicie który można edytować za pomocą zwykłego edytora tekstu lub za pomocą graficznych narzędzi do edycji menu.

Prostym przykładem treści może być:

[Desktop Entry]
Type=Application
Name=Rectball
Comment=Match gems and collect points in this puzzle game
Categories=Game;
Exec=Rectball
Icon=rectball

W tym przykładzie kluczem jest Exec wskazuje polecenie, które ma zostać wykonane (bez ścieżki bezwzględnej) i, jeśli w Twoim AppRun konfiguruje ścieżkę PATH, aby uwzględnić ${HERE}/usr/binSystem bez problemu znajdzie plik binarny. Należy podkreślić, że:

• Wpis w kategorii jest wymagany dla wielu narzędzi związanych z AppImage (na przykład niektóre warianty linuxdeploy kończą się niepowodzeniem, jeśli nie są zdefiniowane).
• Klucz Ikona Zwykle jest mapowany na typ pliku nombre.png o nombre.svg który powinien być dostępny w oczekiwanych katalogach ikon (na przykład w AppDir pod usr/share/icons lub obok .desktop, w zależności od przepływu pracy).

W niektórych prawdziwych obrazach AppImage klawisz „Ikona” jest pomijany lub obsługiwany nieco inaczej. Mimo to, jeśli chcesz uniknąć niespodzianek (na przykład nieprawidłowego wyświetlania ikon przy użyciu formatu .png zamiast .svg), warto to zrobić. Zdefiniuj ikonę wyraźnie i sprawdź, czy wygląda dobrze na kilku dystrybucjach..

Skrypt AppRun: serce realizacji w AppImage

plik Apprun To punkt wejścia dla pliku AppImage. Gdy użytkownik uruchamia plik .AppImage, w rzeczywistości uruchamiany jest program AppRun w zamontowanym katalogu AppDir. Ten skrypt może być prostym skryptem powłoki, który:

• Rozwiąż rzeczywistą ścieżkę, z której jest uruchamiany (biorąc pod uwagę łącza symboliczne i zespoły czasowe).
• Przygotuj zmienne środowiskowe takie jak PATH, LD_LIBRARY_PATH i inne, których program potrzebuje do znalezienia bibliotek lub zasobów.
• Uruchom rzeczywisty plik wykonywalny (albo odczytując klucz Exec z .desktop albo wywołując bezpośrednio usr/bin/miapp).

Bardzo powszechny wzorzec, który znajdziesz w AppImageKit, wygląda mniej więcej tak:

#!/bin/sh
SELF=$(readlink -f "$0")
HERE=${SELF%/*}

export PATH="${HERE}/usr/bin:$PATH"
export LD_LIBRARY_PATH="${HERE}/usr/lib:$LD_LIBRARY_PATH"

EXEC=$(grep -e '^Exec=' "${HERE}"/*.desktop | head -n 1 | cut -d '=' -f 2 | cut -d ' ' -f 1)
exec "${EXEC}" "$@"

To podejście dynamicznie poszukuje wartości Exec w pliku .desktop i uruchamia go z argumentami przekazanymi przez użytkownika, co jest bardzo elastyczne. Inne projekty wybierają jeszcze prostsze wersje. Na przykład AppImage firmy Neovim używa minimalistycznego AppRun w następujący sposób:

#!/bin/bash
unset ARGV0
exec "$(dirname "$(readlink -f "${0}")")/usr/bin/nvim" ${@+"$@"}

Niezależnie od tego, którą wersję wybierzesz, idea jest taka, że ​​AppRun Nie jest zależny od ścieżek systemowych i może działać poprawnie w dowolnej lokalizacji. gdzie zamontowany jest AppImage.

Narzędzia do tworzenia obrazów aplikacji: linuxdeploy, AppImageKit i Pkg2appimage

Tworząc własny pakiet AppImage, masz do dyspozycji kilka głównych narzędzi, z których każde ma swój własny cel. Najbardziej polecane dla nowoczesnych przepływów pracy jest linuxdeploychociaż AppImageKit i Pkg2appimage nadal mają swoje miejsce.

linuxdeploy zajmuje się Przeanalizuj plik wykonywalny, wykryj jego zależności i automatycznie zbuduj strukturę AppDir. odpowiednie (kopiowanie bibliotek do usr/lib(organizowanie plików itp.). Jest to szczególnie przydatne, gdy masz już działający plik binarny i chcesz go spakować, nie kłopocząc się zbytnio nad tym, jakie biblioteki uwzględnić.

Ze swojej strony, AppImageKit Zapewnia między innymi narzędzie narzędzie obrazu aplikacjiktóry przyjmuje już zamontowany katalog AppDir jako dane wejściowe i generuje na jego podstawie plik .AppImage. Możesz pobrać appimagetool bezpośrednio z repozytorium GitHub; co ciekawe, Jest dystrybuowany jako AppImageTypowe zastosowanie:

./appimagetool-x86_64.AppImage MiApp.AppDir MiApp-x86_64.AppImage

W środowiskach takich jak Docker czy CI ważne jest, aby pamiętać, że AppImageKit wymaga FUSE aby móc zamontować obraz wewnętrznie. Jeśli FUSE nie jest dostępny w kontenerze lub na komputerze, proces może się nie powieść, dlatego zaleca się sprawdzenie tego przed automatyzacją kompilacji.

Trzecim ważnym elementem jest Obraz Pkg2app, przeznaczony dla przypadków, gdy posiadasz już istniejący pakiet (na przykład, tar.gz, .deb, a nawet repozytoria PPAi chcesz przekonwertować go na AppImage. To narzędzie jest kontrolowane przez plik opisu .yml, w którym definiujesz, skąd pobierane jest oprogramowanie, w jaki sposób instalowane są pakiety i jakie pliki znajdą się w docelowym katalogu AppDir.

Typowy sposób pracy z Pkg2appimage wygląda mniej więcej tak:

1. Sklonuj repozytorium z odpowiednim plikiem .yml. dla aplikacji, którą chcesz przekonwertować (na przykład dostosowany plik YAML Packet Tracer).
2. Pobierz Pkg2appimage ze swojego repozytorium GitHub i nadaj mu uprawnienia do wykonywania za pomocą chmod +x.
3. Dostosuj plik .yml aby zaktualizować adresy URL pobierania, które uległy zmianie lub nowe zależności.
4. Rzucać ./pkg2appimage NombreArchivo.yml i poczekaj, aż wygenerowane zostaną końcowe AppDir i AppImage.

To podejście jest bardzo praktyczne dla Poddaj recyklingowi istniejące pakiety, które nie działają dobrze w Twojej dystrybucji lub wymagających złożonej instalacji bibliotek o niższej wersji. Pkg2appimage automatyzuje znaczną część tej pracy i udostępnia gotowy do użycia plik .AppImage dla różnych systemów.

Utwórz obraz aplikacji z własnego pliku wykonywalnego krok po kroku

Wyobraź sobie, że masz prosty program, na przykład projekt o nazwie Witaj świecie, z jego binarnym w bin/ i ich biblioteki w lib/Możesz spakować go jako plik .zip, dowiedz się, jak wygenerować plik .deb lub .rpm, ale możesz też Skorzystaj z okazji i spakuj go jako obraz aplikacjiPrzepływ pracy z linuxdeploy jest zazwyczaj dość prosty.

Podstawowe kroki wyglądają następująco: kluczowe kroki

1. Przygotuj środowisko i pobierz linuxdeploy

Pierwszy to Pobierz narzędzie linuxdeploy i nadaj mu uprawnienia wykonywalne.Zwykle jest on dystrybuowany w postaci gotowych do użycia plików binarnych (na przykład jako AppImage). terminalcoś takiego:

wget https://github.com/linuxdeploy/linuxdeploy/releases/.../linuxdeploy-x86_64.AppImage
chmod +x linuxdeploy-x86_64.AppImage

Ponadto, jeśli planujesz oferować wydajne aktualizacje za pomocą zsyncNarzędzie zsync można zainstalować na przykład w systemach opartych na Debianie/Ubuntu za pomocą:

sudo apt-get install zsync

2. Zbuduj strukturę AppDir

Następnie utwórz katalog, który będzie funkcjonował jako AppDir (na przykład, MiApp.AppDira w środku organizujesz minimalna struktura To konieczne. Możesz to zrobić ręcznie lub pozwolić linuxdeploy wygenerować część pliku. Pomysł jest taki:

• Umieść swój główny plik wykonywalny w MiApp.AppDir/usr/bin/, Na przykład MiApp.AppDir/usr/bin/hello-world.
• Zezwól programowi linuxdeploy na automatyczne kopiowanie wymaganych bibliotek a MiApp.AppDir/usr/lib/ gdy uruchomisz go z odpowiednimi opcjami.
• Utwórz plik .desktop w ciągu MiApp.AppDir/usr/share/applications/ z poprawnymi polami: Nazwa, Komentarz, Dyrektor, Ikona, Kategorie, itd.
• Przygotuj ikony i umieść je na typowych trasach MiApp.AppDir/usr/share/icons/hicolor/, upewniając się, że wartość klucza Icon w .desktop odpowiada nazwie pliku (bez rozszerzenia).

Ważne jest, aby pamiętać, że w polu .desktop Exec powinien wskazywać na nazwę pliku wykonywalnego dokładnie tak, jak będzie jej szukał linuxdeploy usr/bin. Jeśli użyjesz Exec=hello-worldlinuxdeploy założy, że w usr/bin Ten plik wykonywalny istnieje.

3. Uruchom linuxdeploy, aby spakować aplikację

Mając strukturę AppDir, wskazać trasę do AppDir i opcjonalnie określonych modułów lub wtyczek (na przykład w celu integracji ikon, plików .desktop itp.). linuxdeploy obsługuje:

• Przeskanuj główny plik binarny i wykryć, jakich bibliotek dynamicznych potrzebuje.
• Skopiuj te biblioteki do usr/lib w AppDir, pod warunkiem, że nie są to biblioteki, które prawdopodobnie już istnieją w systemie użytkownika.
• Przygotuj AppDir tak, aby później mogło stać się obrazem AppImage (czasami sam linuxdeploy może wygenerować obraz AppImage w połączeniu z wtyczkami).

Po tym procesie w bieżącym katalogu będzie znajdował się plik z rozszerzeniem. .Obraz aplikacji, jak na przykład hello-world-x86_64.AppImagektóry możesz skopiować gdziekolwiek chcesz i uruchomić na innych kompatybilnych systemach GNU/Linux.

4. Uczyń go wykonywalnym i przetestuj na różnych dystrybucjach

Gdy linuxdeploy (lub appimagetool) generuje obraz aplikacji, bardzo prawdopodobne jest, że na początku nie ustaw bitu wykonaniaW takim przypadku wystarczy wykonać następujące czynności:

chmod +x hello-world-x86_64.AppImage
./hello-world-x86_64.AppImage

Zdecydowanie zaleca się Przetestuj swój obraz aplikacji w różnych dystrybucjach i wersjachObejmuje to stosunkowo starą wersję w zakresie, który chcesz obsługiwać (na przykład minimalną wersję Ubuntu lub Debiana, którą zamierzasz obsługiwać). Dzięki temu masz pewność, że nie pominąłeś żadnych istotnych zależności i że plik wykonywalny zachowuje się wszędzie tak samo.