Jak stworzyć pakiet TGZex

Niezbędne informacje

Pakiety TGZex są rozszerzoną wersją dobrze wszystkim znanych TGZ ze Slackware. Budowa pakietu jest bardzo prosta - jest to skompresowane archiwum TAR, zawierające drzewo katalogów. Opis ten dotyczy jedynie samej metodyki budowy pakietu od strony technicznej. Odpowiednia kompilacja, patche itd. nadal zależą od osoby paczkującej. Jeżeli nie posiadasz odpowiedniej wiedzy i umiejętności praktycznych, postępowanie zgodnie z tym HOWTO nie gwarantuje, że stworzony pakiet będzie poprawnie działał. Ponieważ jednak nie da się opisać wszystkiego, co osoba paczkująca powinna wiedzieć, zajmiemy się jedynie podstawami. Zanim zabierzemy się za tworzenie pakietu musimy najpierw skompilować program (obiekt, który ma być pakowany). Musimy pamiętać, aby kompilować pakiet najlepiej na czystej instalacji KateOS, tak żeby użytkownicy systemu nie mieli potem problemu z zależnościami. Zanim zabierzemy się za kompilację należy uważnie przeczytać pliki README i INSTALL znajdujące się w archiwum źródeł. Należy zawsze brać pod uwagę wszelkie problemy jakie mogą wystąpić. Pamiętajmy też, aby odpowiednio wyselekcjonować opcje dodatkowe programu, niektóre pozornie przydatne mogą zdestabilizować program oraz niepotrzebnie zwiększyć wymagania programu. Kolejną ważną rzeczą przy kompilacji oprogramowania jest ustawienie odpowiednich flag dla kompilatora. Domyślnie przy tworzeniu paczek dla KateOS są używane flagi -O2 -march=i486 -mtune=i686 -pipe. Pamiętajmy, aby do kompilacji używać domyślnego kompilatora znajdującego się w dystrybucji. Jeżeli mamy do czynienia ze standardowym archiwum źródeł, to procedura podstawowa jest prosta: ./configure && make && make install DESTDIR=/$sciezkadokatalogutymczasowego. Pamiętajmy jednak, że jest to jedynie przykład postępowania ze źródłami, nie wolno nam zapomnieć o miejscach w których powinny się znajdować poszczególne części programu. Zakładamy, że:

• Programy, biblioteki absolutnie wymagane do startu systemu i jego prawidłowego funkcjonowania znajdują się w korzeniu systemu, czyli w "/".

• Programy uważane za ważne dla systemu, czyli wszelkie serwery, środowiska graficzne, programy multimedialne itd. powinny się znajdować w katalogu /usr.

• Gry powinny się znajdować w katalogu /usr/, a ich binaria w katalogu /usr/games.

• Wszystkie programy, biblioteki o najmniejszym znaczeniu dla systemu, absolutnie opcjonalne należy umieszczać w katalogu /opt.

• Strony manuala powinny się znajdować w /usr/man.

• Pliki z rozszerzeniem *.desktop służące jako część menu w standardzie freedesktop.org powinny się znajdować w katalogu /usr/share/applications

• Ikonki służące plikom *.desktop powinny znajdować się w katalogu /usr/share/pixmaps, lub ewentualnie w /usr/share/icons.

• Pliki "*.info" należy umieszczać w katalogu /usr/info/.

• W pakietach nie mają prawa znaleźć się pliki cache zawierające jakiekolwiek ustawienia tymczasowe (np. cache ikon itp.)

Zawartość każdego pakietu powinna mieć nałożone odpowiednie prawa. Domyślnym właścicielem plików powinien być root.root z prawami 755. Wszelkie pliki wykonywalne powinny być obdarzone prawami 755 oraz właścicielem root.bin, z wyjątkiem gier, których prawa powinny być 754 root.games. Wykorzystywanie grupy bin nie jest czymś szczególnie ważnym, jednak ciężko porzucić tą tradycję. Pliki tekstowe, które nie powinny być modyfikowane (strony man'a, dokumentacje...) powinny mieć nałożone prawa 644 z właścicielem root.root. Pliki, które wymagają innych praw powinny mieć je odpowiednio ustawiane. Pamiętajmy także, aby unikać tam gdzie to możliwe uruchamiania wszelkich demonów oraz serwerów z prawami roota. Tam gdzie się da, należy wykorzystywać alternatywnych użytkowników, grupy stworzone w tym konkretnym celu. Pamiętajmy, że specjalni użytkownicy, grupy mają dostępne jedynie id do 500, powyżej zostawiamy numerki dla użytkowników. Konkretne pakiety mają przydzielone także swoje konkretne grupy na ustalonych id, więc zanim pokusimy się o tworzenie nowej grupy dla programu znajdującego się w pakiecie, sprawdźmy czy dane id nie jest już wykorzystywane w innym pakiecie. W tym celu najlepiej zapytać kogoś z Kate_Teamu (w tej chwili - 19112006 - najlepiej zorientowaną osobą będzie Damian).

Budowa pakietu TGZex

Pakiety KateOS składają się z drzewa katalogów zaczynającego się od korzenia oraz z dodatkowego katalogu install zawierającego szczególną dla pakietu zawartość. Oto zawartość przykładowego pakietu (wpis został skrócony):

Łatwo zauważyć, że katalog install zawiera kilka dziwnych plików.

Plik build jest zwykłym plikiem tekstowym, zwierającym jedynie datę w formacie DDMMYYYY.

Pliki slack-desc* zawierają opis pakietu, oto przykładowa zawartość takiego pliku:

     |-----handy-ruler------------------------------------------------------|

Należy pamiętać, aby opis pakietu nie wykraczał poza "Handy ruler". W pierwszej linijce powinna znajdować się nazwa pakietu wraz z krótkim opisem w nawiasie, potem wolna linijka a następnie właściwy opis. Dla plików reprezentujących dodatkowe tłumaczenie musimy pamiętać o sufiksie reprezentującym odpowiednie 'locale'. Np. opis w języku polskim powinien być kodowany w standardzie iso8859-2, a plik z nim powinien posiadać nazwę slack-desc.pl_PL.

Plik deps zawiera listing zależności pakietu. Jego zawartość może wyglądać tak:

Jak widać zależności listowane są linia po linii. Wpisywana jest jedynie główna nazwa wymaganego pakietu.

Plik doinst.sh Zawiera skrypt, który najczęściej tworzy linki do bibliotek, sprawdza czy pliki konfiguracyjne zostały zmienione, często w tym skrypcie dodaje się grupę lub użytkownika.

Przykładowa zawartość pliku:

 NEW="$1"

 OLD="`dirname $NEW`/`basename $NEW .new`"

{tu hash} If there's no config file by that name, mv it over:

 if [ ! -r $OLD ]; then

   mv $NEW $OLD

 elif [ "`cat $OLD | md5sum`" = "`cat $NEW | md5sum`" ]; then # toss the redundant copy

   rm $NEW

 fi

{tu hash} Otherwise, we leave the .new copy for the admin to consider...

Plik preinst.sh jest skryptem, który jest wykonywany przed instalacją pakietu (np. by wyłączyć jakąś usługę).

Przykładowa zawartość:

Plik postinst.sh to skrypt, który jest wykonywany po instalacji pakietu i przed jego usunięciem. Tutaj możemy umieścić dodawanie lub usuwanie odpowiednich użytkowników, czy grup. Jeżeli pakiet przed instalacją zatrzymał jakiś serwer/proces, to tutaj jest miejsce aby serwer włączyć z powrotem. Plik ten zawiera zawsze dwie funkcje: afterinstall oraz beforeremove. Jak same nazwy wskazują w ciałach tych funkcji zamieszczamy odpowiednio dla beforeremove kod, który ma być wykonywany przed usunięciem pakietu, oraz dla afterinstall kod wykonywany po instalacji pakietu.

Przykładowa zawartość pliku:

Tworzenie pakietu

Gdy już skompilowaliśmy nasz program, wykonujemy polecenie make install DESTDIR=/$sciezka_do_katalogu_tymczasowego, gdzie zmienna $sciezka_do_katalogu_tymczasowego określa nasz katalog roboczy, w którym będziemy tworzyć pakiet. Gdy już to zrobimy umieszczamy wcześniej przygotowane wymagane pliki do katalogu install, ustawiamy prawa dla plików, oraz odpowiednio stripujemy binaria (najlepiej w katalogu roboczym tradycyjnie wykonać:

 find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
 find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null

Ostatecznym ruchem jest wejście do katalogu roboczego i stworzenie pakietu za pomocą komendy makepkg. Program zapyta nas, czy znalezione dowiązania symboliczne ma umieścić w pliku doinst.sh, zawsze odpowiadamy, że tak, ponieważ dowiązania nie powinny znajdować się w drzewie katalogów. Pamiętajmy o odpowiedniej nazwie pakietu! Jest ona tradycyjnie prowadzona z małej litery i wygląda tak:

{nazwa-pakietu}-{wersja programu}-{architektura}-{wersja pakietu}.tgz

Wersja programu nie może zawierać myślników, architektura powinna być ustalana na podstawie wcześniej używanej flagi -march, czyli jeżeli program będzie działać na 486 to wpisujemy właśnie i486. Wersja pakietu to domyślnie 1, zmieniamy ją w momencie, gdy pakietujemy jeszcze raz program w tej samej wersji i chcemy odróżnić starszy pakiet od nowego. NIGDY NIE WOLNO IGNOROWAĆ DATY ZNAJDUJĄCEJ SIĘ W PLIKU build ANI WERSJI PAKIETU !!!

Jeżeli zastosujemy się do wyżej wymienionych instrukcji i będziemy używać mózgu w czasie tworzenia pakietu, to otrzymamy dobrą paczuszkę, którą będziemy mogli się podzielić z pozostałymi użytkownikami :) Zanim jednak zaczniemy się cieszyć warto z użytkownika "root" wykonać na pakiecie komendę testpkg (testpkg $sciezka_do_pakietu). Narzędzie to wstępnie sprawdzi jego zawartość i poinformuje nas o ewentualnych błędach. Paczka, która posiada błędy musi być poprawiona.

Gotową paczką możemy się dzielić ze społecznością. Pamiętajmy jednak, że tak stworzony pakiet nie zostanie przyjęty jako oficjalna paczka dystrybucyjna. Developerzy i maintainerzy pakietów KateOS muszą pamiętać o skryptyach .build i zestawie źródłowym paczki. Jest to jednak temat na inny artykuł.

Warto przeglądać zawartość innych paczek (dowolnym programem archiwizującym), oraz czytać skrypty .build, to zdecydowanie ułatwi naukę.

Użyteczne wskazówki

• Zanim uruchomich makepkg utwórz w katalogu tymczasowym pusty katalog install, aby skrypt mógł sam stworzyć wszystkie wymagane pliki
• Podczas instalowania programów związanych ze środowiskiem KDE (np. amarok) używaj --prefix=`kde-config --prefix` co zwróci prefix do aplikacji dedykowanych dla KDE
• Po stworzeniu paczki możesz "przetestować" ją wydając polecenie testpkg twoja-paczka.tgz
• Należy kompresować strony manuali na przykład wchodząc do katalogu z manuali i wydając polecenie gzip *]
• Często należy tworzyć w katalogu programu podkatalog doc/nazwa_programu-wersja do którego kopiuje się takie pliki jak: LICENSE, AUTHORS, COPYING, INSTALL, NEWS, README, THANKS, TODO
• Zmiany uprawnień plików binarnych na root:bin trzeba dokonać własnoręcznie
• Jeżeli utworzymy katalog install skrypt sam utworzy plik z opisem [slack-desc], plik z datą [build], zapyta się o wykrycie zależności i sam stworzy plik z zależnościami [deps]
• Często paczkę tworzy się "dwa razy". Za pierwszym razem pozwala się aby makepkg stworzył wszystkie potrzebne pliki. Następnie tworzy się plik slack-build.$LOCALE, testuje powstałą paczkę przez testpkg, poprawia wyplute błędy a następnie, usuwa się starą i ponownie poprzez makepkg tworzy nową paczkę.
• Podczas tworzenia paczki drugi raz skasuj poprzednią paczkę z katalogu
• Paczki z gotowych binariów twórz do katalogu /opt

Categories: Paczki