Menadżer Pakietów RedHat-a (RPM) - Jak To Zrobić: Tworzenie rpm-ów. Następna strona Poprzednia strona Spis treści 6. Tworzenie rpm-ów. Tworzenie rpm-ów jest dość proste, szczególnie jeśli oprogramowanie które chcesz w nie włożyć poprawnie się instaluje. Procedura tworzenia RPM-ów wygląda tak: Upewnij się, że plik /etc/rpmrc jest obecny i poprawnie skonfigurowany w Twoim systemie. Doprowadź to tego, że pliki źródłowe dla których tworzysz rpm poprawnie się instalują. Przygotuj listę poprawek jakich musiałeś dokonać by kod kompilował się poprawnie. Przygotuj plik specyfikujący (.spec) dla Twojego pakietu. Upewnij się, że wszystko jest na swoim miejscu. Zbuduj pakiet używając rpm. Zazwyczaj RPM tworzy zarówno pakiety binarne jak i źródłowe. 6.1 Plik rpmrc W chwili obecnej, jedyny sposób konfiguracji RPM-a jest dostępny poprzez plik /etc/rpmrc. Przykładowy plik wygląda tak: require_vendor: 1 distribution: Moja własna dystrybucja! require_distribution: 1 topdir: /usr/src/me vendor: Kubuśsoft packager: Pakujący RPM w Kubuśsoft <pakiety@kubuśsoft.com.pl> optflags: i386 -O2 -m486 -fno-strength-reduce optflags: alpha -O2 optflags: sparc -O2 signature: pgp pgp_name: Pakujący RPM w Kubuśsoft pgp_path: /home/pakiety/.pgp tmppath: /usr/tmp Wiersz require_vendor zmusza RPM-a do szukania wiersza z nazwą producenta pakietów (vendor). Ta może pochodzić z pliku /etc/rpmrc lub z nagłówka pliku .spec. By wyłączyć tę opcję, zmień liczbę na 0. Analogicznie jest w przypadku wierszy require_distribution oraz require_group. Następnym wiersz zawiera distribution i określa nazwę dystrybucji. Możesz ją zdefiniować tutaj, bądź później, w nagłówku pliku specyfikującego. Tworząc pakiet dla konkretnej dystrybucji warto zadbać by wiersz ten zawierał poprawną informację, nawet pomimo tego, że nie jest wymagany. Tyczy się to również wiersza vendor (producent), choć nazwa może być zupełnie dowolna (np. Joe's Software, Rock Music Emporium). RPM pozwala również tworzyć pakiety dla różnych platform sprzętowych. Plik rpmrc może zawierać zmienną ``optflags'' wykorzystywaną przy building budowaniu tych elementów pakietu, które wymagają opcji zależnych od platformy. Dokładniejszy opis tej zmiennej pojawi się w jednym z następnych rodziałów. Nie są to oczywiście wszystkie etykiety/makra. Jest ich więcej. By się im przyjrzeć spróbuj komendy: rpm --showrc która powinna wypisać wszystkie możliwe etykiety wraz z ich wartościami (o ile są ustawione). 6.2 Plik specyfikujący .spec Niniejszy rozdział zawiera opis pliku specyfikującego dla pakietu. Plik taki są niezbędne by stworzyć pakiet. Zawiera on opis oprogramowania wraz z instrukcjami instalacyjnymi oraz listę wszystkich plików binarnych przez niego instalowanych. Plik specyfikujący warto jest nazwać zgodnie z konwencją. Powinno to wyglądać mniej więcej tak: nazwa pakietu-kreska-numer wersji-kreska-numer modyfikacji-kropka-spec. A tak wygląda przykładowy plik specyfikujący (eject-3.0-1.spec): Summary: ejects ejectable media and controls auto ejection Name: eject Version: 1.4 Release: 3 Copyright: GPL Group: Utilities/System Source: sunsite.unc.edu:/pub/Linux/utils/disk-management/eject-1.4.tar.gz Patch: eject-1.4-make.patch Patch1: eject-1.4-jaz.patch %description This program allows the user to eject media that is autoejecting like CD-ROMs, Jaz and Zip drives, and floppy drives on SPARC machines. %prep %setup %patch -p1 %patch1 -p1 %build make RPM_OPT_FLAGS="$RPM_OPT_FLAGS" %install install -s -m 755 -o 0 -g 0 eject /usr/bin/eject install -m 644 -o 0 -g 0 eject.1 /usr/man/man1 %files %doc README COPYING ChangeLog /usr/bin/eject /usr/man/man1/eject.1 6.3 Nagłówek Nagłówek pliku .spec zawiera kilka standardowych pól które powinny być wypełnione. Oto znaczenie poszczególnych pól: Summary: Jest to jednowierszowy, skrócony opis pakietu. Name: To pole zawiera nazwę pliku rpm. Ściśle jest to string będący tą częścią nazwy pliku rpm która odpowiada nazwie pakietu. Version: To pole zawiera wersję pliku rpm. Ściśle jest to string będący tą częścią nazwy pliku rpm która odpowiada wersji pakietu. Release: To pole zawiera numer modyfikacji pliku rpm. Jest to liczba mówiąca z którą modyfikacją (podwersją) obecnej wersji pakietu mamy do czynienia (tzn. jeśli dokonany w pakiecie tylko minimalnych poprawek błędów to wypuszczamy pakiet w tej samej wersji ale z numerem modyfikacji większym o jeden). Icon: To pole zawiera nazwę pliku z ikoną przeznaczoną do wykorzystania przez narzędzia instalacyjne wyższego poziomu (np. ``glint'' RedHat-a). Plik ten powinien być zapisany w formacie GIF i znajdować się w katalogu SOURCES. Source: This wiersz zawiera nazwę pliku źródłowego z którego jest budowany dany rpm. Jest to pomocne w sytuacji gdy chce się kiedyś zajrzeć do odpowiednich kodów źródłowych lub sprawdzić czy nie ma ich nowszej wersji. Uwaga: Nazwa pliku w tym wierszu MUSI odpowiadać nazwie pliku obecnego w Twoim systemie. (tzn. nie zmieniaj nazw plików źródłowych po ich ściągnięciu). Można podać więcej niż jeden plik źródłowy pisząc w poniższy sposób: Source0: blah-0.tar.gz Source1: blah-1.tar.gz Source2: fooblah.tar.gz Te pliki powinny się znaleźć w katalogu SOURCES. (Struktura tego katalogu jest opisana w rozdziale "Katalogi z plikami źródłowymi".) Patch: To pole zawiera miejsce w którym będzie można znaleźć poprawki(patch) jeśli zainstnieje potrzeba ich ponownego ściągnięcia. Uwaga: Nazwa tego pliku musi odpowiadać nazwie pliku jaki jest użyty do naniesienia Twoich poprawek. Można też podać wiele plików z poprawkami analogicznie do wielu plików źródłowych: Patch0: blah-0.patch Patch1: blah-1.patch Patch2: fooblah.patch Te pliki powinny się znaleźć w katalogu SOURCES. Copyright: Ten wiersz opisuje do jakiej kategorii ze względu na prawo autorskie należy dane oprogramowanie. Najlepiej wykorzystać jedną z dobrze zdefiniowanych kategorii: GPL, BSD, MIT, public domain, distributable, lub commercial. BuildRoot: Ten wiersz pozwala zdefiniować główny katalog (``root'') dla tworzenia i instalacji pakietu. Można to wykorzystać np. do testowania instalacji pakietu zanim się go zainstaluje w docelowym miejscu. Group: Ten wiersz służy do tego, by programy instalacyjne wyższego poziomu (wspomniany ``glint'') wiedziały w jakim miejscu ich hierarchicznej struktury grup pakietów umieścić dany pakiet. W chwili obecnej drzewo grup pakietów wygląda mniej więcej tak: Applications Communications Editors Emacs Engineering Spreadsheets Databases Graphics Networking Mail Math News Publishing TeX Base Kernel Utilities Archiving Console File System Terminal Text Daemons Documentation X11 XFree86 Servers Applications Graphics Networking Games Strategy Video Amusements Utilities Libraries Window Managers Libraries Networking Admin Daemons News Utilities Development Debuggers Libraries Libc Languages Fortran Tcl Building Version Control Tools Shells Games %description Nie jest to element nagłówka w ścisłym tego słowa znaczeniu ale jego opis powinien się znaleźć wraz z opisem nagłówka. Dla każdego pakietu lub subpakietu potrzebne jest jedno takie pole zawierające przejrzysty i zrozumiały opis pakietu. 6.4 Sekcja Prep Jest to druga część pliku specyfikującego. Używa się jej do przygotowania źródeł do kompilacji/instalacji. W niej powinny znajdować się wszystkie czynności niezbędne by nanieść poprawki do źródeł i doprowadzić je do stanu w którym będzie można wydać komendę make. Jedną rzecz należy podkreślić: Każda z tych części jest tak naprawdę tylko miejscem do umieszczenia odpowiednich skryptów. Możesz po prostu napisać skrypt w sh a następnie umieścić go po znaczniku %prep by rozpakować i wprowadzić poprawki do swoich programów. By to ułatwić powstały specjalne makra. Pierwszym z nich jest makro %setup. W swojej najprostszej formie (bez dodatkowych opcji w linii poleceń), rozpakowywuje ona źródła i zmienia bieżący katalog na katalog zawierający źródła. Poza tym ma jednak dodatkowe opcje: -n name ustawi nazwę roboczego katalogu na name. Domyślnie jest to $NAZWA-$WERSJA. Do innych możliwości należą $NAZWA, ${NAZWA}${WERSJA}, czy jakakolwiek inna używana przez główny plik tar. (Proszę zauważyć, że zmienne ``$'' nie są faktycznymi zmiennymi dostępnymi wewnątrz pliku specyfikującego. W rzeczywistości są one tutaj użyte w miejsce przykładowej nazwy. W pakiecie należy użyć rzeczywistej nazwy i wersji, a nie zmiennej.) -c utworzy i wejdzie do wymienionego katalogu zanim zacznie się rozpakowywanie poprzez untar. -b # wykona untar (rozpakuje) Source# zanim wejdzie do katalogu roboczego (nie ma sensu łączenie tej opcji z -c, a więc się tego nie robi). Jest to przydatne w przypadku wielu plików źródłowych. -a # wykona untar (rozpakuje) Source# po wejściu do katalogu. -T Ta opcja zmienia domyślną procedurę rozpakowywania (untar) źródeł i wymaga -b 0 lub -a 0 by główny plik źródłowy został rozpakowany (untar). Komenda ta jest potrzebna gdy używany jest więcej niż jeden komplet plików źródłowych. -D Nie usuwaj katalogu przed rozpakowaniem. Jest ona przydatna tylko wtedy, gdy ma się więcej niż jedno makro konfiguracyjne. Powinna być używana wyłącznie w makrach konfiguracyjnych wyłącznie po wykonaniu pierwszego z nich (ale nigdy węwnątrz pierwszego z nich). Następne dostępne makra znajdują się w makrze %patch. Makro te pomaga zautomatyzować proces nanoszenie poprawek do źródeł. Możliwe są liczne opcje opisane poniżej: # zastosuje Patch# jako plik z poprawkami. -p # podaje liczbę katalogów do odrzucenia z nazwy przed wykorzystaniem polecenia patch(1) -P Domyślnie stosowana jest Patch (lub Patch0). Ta flaga wyłącza to zachowanie a więc wymaga dodatkowo 0 by główne pliki źródłowe zostały rozpakowane. Opcja ta jest przydatna w drugim (bądź dalszym) makrze %patch które wymaga innego niż pierwsze makro numeru poprawki. Można też napisać %patch# zamiast : %patch # -P To są wszystkie makra jakich potrzebujesz. Po ich poprawnym napisaniu można wykonać dowolne inne komendy konfiguracyjne poprzez stworzenie odpowiednich fragmentów skryptów w sh. Wszystko co zostanie umieszczone aż do makra %build (omawianego w następnym rozdziale) będzie wykonane przez sh. Przykłady powyżej mogą sugerować rzeczy jakie chciałbyś tam umieścić. 6.5 Sekcja Build Dla tej sekcji nie ma jakichś specjalnych makr. Powinno się w niej umieszczać dowolne polecenia potrzebne do stworzenia pakietu po rozpakowaniu źródeł, naniesieniu poprawek i przejściu do katalogu roboczego. Jest to po prostu następny zbiór poleceń przekazany do sh, więc można tu używać dowolnych poprawnych poleceń sh (włącznie z komentarzami). Katalog roboczy na początku każdej z sekcji jest ustawiany na katalog główny z plikami źródłowymi, o czym trzeba pamiętać i w razie potrzeby przechodzić do odpowiednich podkatalogów. 6.6 Sekcja Install Tu również nie ma jakichś specjalnych makr. Sekcja ta powinna zawierać listę poleceń potrzebnych do instalacji pakietu. Jeśli wykonujesz make install by zainstalować pakiet, umieść to tu. Możesz również nanieść poprawki do makefile'a zanim wykonasz make install. Jeśli nie to umieść tu sekwencję poleceń sh jakich potrzebujesz. Katalog roboczy, identycznie jak w poprzednim przypadku, jest ustawiany przed wykonaniem tych poleceń na główny katalog z plikami źródłowymi. 6.7 Opcjonalne sekcje pre i post dla sekcji Install/Uninstall Możesz tu umieścić skrypty do wykonania przed i po instalacji/deinstalacji (tzn. sekcjami Install/Uninstall). Główny powód to np. potrzeba wykonania komendy ldconfig po instalacji bądź usuwaniu pakietów zawierających biblioteki dzielone. Makra są zdefiniowane jak poniżej: %pre makro z poleceniami wykonywanymi przed sekcją Install. %post makro z poleceniami wykonywanymi po sekcji Install. %preun makro z poleceniami wykonywanymi przed sekcją Uninstall. %postun makro z poleceniami wykonywanymi po sekcji Uninstall. Sekcje te mogą zawierać dowolne poprawne polecenia sh ( nie potrzebujesz wstawiać #!/bin/sh na początku). 6.8 Sekcja Files W sekcji tej musisz wypisać pliki jakie wchodzą w skład pakietu. RPM nie potrafi określić jakie pliki zostają zainstalowan na skutek np. make install. Tego się po prostu NIE DA rozsądnie zrobić. Owszem, była propozycja wykonywania polecenia find przed i po instalacji pakietu. Jednak w systemach wieloużytkownikowych nie jest to zbyt sensowne gdyż w tym samym czasie mogło powstać wiele innych plików nie mających najmniejszego związku z instalowanym pakietem. W tej sekcji dostępne jest pare specjalnych makr. Są one opisane poniżej: %doc służy do zaznaczenia które pliki pakietu są jego dokumentacją. Dokumentacja ta zostanie umieszczona w katalogu: /usr/doc/$NAZWA-$WERSJA-$MODYFIKACJA. Można zarówno podać nazwy kilku plików w linii zawierającej to makro jak i podać te nazwy oddzielnie używając makra dla każdej z nich. %config służy do zaznaczenia plików konfiguracyjnych w obrębie pakietu. Chodzi tu o pliki typu: sendmail.cf, passwd, etc. W trakcie deinstalacji pliki te są usuwane o ile nie były zmieniane. Jeśli były, to ich nazwa zostaje zmieniona poprzez dodanie końcówki .rpmsave. Analogicznie jak dla plików z dokumentacją jedno makro może służyć do zdefiniowania kilku takich plików. %dir zaznacza dany katalog jako należący do pakietu. Domyślnie, jeśli pojawi się nazwa katalogu BEZ makra %dir, WSZYSTKO w tym katalogu jest włączane w liste plików i następnie instalowane jako część pakietu. To makro pozwala tego uniknąć. %files -f <filename> pozwala na włączenie listy plików znajdującej się w jakimś pliku w obrębie katalogu z plikami źródłowymi. Jest to wygodne gdy procedura instalacji buduje własną listę plików którą następnie można włączyć jedną komendą bez podawania nazw tych plików. Największą trudnością w liście plików jest podawanie katalagów. Jeśli np. podasz przez pomyłkę /usr/bin, to Twój pakiet rpm będzie zawierał wszystkie pliki w katalogu /usr/bin w Twoim komputerze. 6.9 Tworzenie pakietu Katalogi z plikami źródłowymi Jedną z podstawowych rzeczy jest poprawnie skonfigurowane katalogów w których RPM będzie budował pakiet. Robi się to poprzez plik /etc/rpmrc. Większość osób używa po prostu /usr/src. Możliwe, że będziesz potrzebował utworzyć poniższe katalogi: BUILD jest katalogiem w którym RPM buduje pakiet. Próbne tworzenie pakietu możesz wykonać w jakimkolwiek katalogu który tu podasz. SOURCES jest katalogiem w którym powinieneś umieścić oryginalne pliki źródłowe i pliki z poprawkami. Jest to miejsce do którego RPM będzie zaglądał domyślnie. SPECS jest katalogiem w którym powinny się znaleźć wszystkie pliki specyfikujące (spec). RPMS RPM umieści tu binarme pliki RPM po ich zbudowaniu. SRPMS RPM umieści to pliki RPM z plikami źródłowymi. Próbne tworzenie pakietu Pierwszą rzeczą do zroienia jest doprowadzenie plików źródłowych do takiego stanu by kompilowały i/lub instalowały się bez pomocy RPM-a. By to osiągnąć, rozpakuj źródła i zmień nazwę katalogu na $NAZWA.orig. Następnie ponownie rozpakuj źródła i pracuj na nich. Wejdź do ich katalogu i postępuj zgodnie z instrukcjia ich instalacji/kompilacji. Jeśli będzie konieczna edycja jakichś plików to konieczne będzie wygenerowanie pliku z poprawkami (patch). Jeśli doprowadzisz źródła do stanu w którym będą się poprawnie instalować/kompilować - wyczyść katalog źródłowy. Upewnij się, że wszystkie pliki stworzone w skrypcie konfiguracyjnym (configure) zostały usunięte. Następnie wyjdź z katalogu źródłowego i wykonaj coś takiego: diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch (dirname w tym przykładzie to to samo co $NAZWA parę linii powyżej). Polecenie to stworzy plik z poprawkami jaki będzie mógł być wykorzystany w pliku specyfikujący. Zauważ, że ``linux'' w nazwie pliku z poprawkami jest jakimś wybranym identyfikatorem. Zamiast tego można użyć czegoś bardziej precyzyjnego jak np. ``config'' lub ``bugs'' (błędy) by opisać dlaczego poprawki były potrzebne. Przed użyciem pliku z poprawkami warto do niego zajrzeć by się upewnić, że przypadkiem nie znalazło się w nim coś niewłaściwego jak np. pliki binarne. Tworzenie listy plików Teraz, gdy źródła się kompilują i instalują i wiadomo jak to robić to zrób to, skompiluj i zainstaluj. Przyjrzyj się wynikowi instalacji i stwórz w ten sposób listę plików do użycia w pliku specyfikującym. Zazwyczaj plik specyfikujący powstaje równocześnie z opisywanymi tu krokami. Po prostu tworzy się go na początku wstawiając to co jest znane i potem w miarę postępu prac uzypełnia się go o brakujące kawałki. Tworzenie pakietu RPM Gdy plik specyfikujący jest gotowy, można już próbować tworzyć nowy pakiet. Najwygodniej jest to zrobić poniższym poleceniem: rpm -ba foobar-1.0.spec Opcja -b ma parę interesującyh podopcji: p oznacza wykonanie sekcji prep pliku specyfikującego. l wykona parę różnych testów na plikach %files. c wykonaj sekcję prep i kompiluj. Jest to przydatne gdy jest się niepewnym czy źródła w ogóle będą się kompilować/instalować. Owszem, na pierwszy rzut oka może to wyglądać na zbędne gdyż można dotąd pracować ze źródłami aż będą się kompilować jednak gdy przyzwyczaisz się do wykorzystania RPM-a to spotkasz się z sytuacjami w którach ta opcja okaże się przydatna. i wykonaj prep, kompiluj i instaluj. b prep, kompiluj, instaluj, i buduj jedynie pakiet binarny. a zbuduj wszystko - zarówno pakiet źródłowy jak i binarny. Jest też parę dodatkowych podopcji do opcji -b: --short-circuit przejdzie prosto do określonego etapu (może być użyte wyłącznie z c oraz i) --clean usuwa katalog ze źródłami stworzony w czasie budowania pakietu. --keep-temps zachowa wszystkie pliki temporalne i skrypty które zostały umieszczone w /tmp. Jakie są to pliki można się dowiedzieć wykorzystując opcję -v. --test nie wykonuje żadnych rzeczywistych etapów choć wykonuje keep-temps. 6.10 Testowanie pakietu Po stworzeniu pakietu rpm źródłowego i binarnego należy je przetestować. Najprościej i najlepiej jest wykorzystać do tego zupełnie inny komputer niż ten na którym pakiet był tworzony. W końcu przy tworzeniu pakietu był on dość często instalowany i na komputerze na którym powstawał powinno być to zrobione dość dobrze. Można też próbować rpm -u nazwapakietu.rpm na testowanym pakiecie ale może być to zdradliwe w sytuacji w której jakieś pliki zostały pominięte w liście plików i nie zostaną wtedy usunięte. Wtedy zainstalowany program będzie kompletny mimo tego, że rpm będzie błędny. Pamiętaj, że ponieważ Ty już zrobiłeś rpm -ba package, to zdecydowana większość osób instalujących Twój pakiet wykona jedynie rpm -i package. Upewnij się, że nie wykonujesz w sekcjach build lub install czegoś co powinno być zrobione gdy instalowany jest wyłącznie pakiet binarny. 6.11 Co robić z Twoimi nowymi RPM-ami ? Gdy już stworzyłeś swój własny pakiet RPM (zakładając, że nie ma już takiego pakietu dostępnego pod postacią RPM) możesz udostępnić wynik swojej pracy innym (zakładając że to czego pakiet stworzyłeś może być tak udostępniane). By udostępnić, umieść to na ftp.redhat.com. 6.12 Co teraz? Prosimy sprawdzić się, że nic nie zostało pominięte jeszcze raz czytając rozdziały o "Testowaniu" i "Co robić z nowymi RPM-ami". Chcemy mieć jako RPM wszystko co się da ale chcemy, żeby były to dobre RPM-y. Prosimy więc poświęcić trochę czasu na ich dokładne przetestowanie i prosimy też o umieszczenie ich w archiwum ftp tak, by każdy mógł z nich skorzystać. A także, prosimy upewnić się, że umieszczasz jedynie bezpłatne oprogramowanie. Oprogramowanie komercyjne i shareware nie powinno być umieszczane w archiwum o ile nie zawierają klauzuli w ich prawach autorskich to dopuszczającej. Dotyczy to np. Netscape, ssh, pgp, etc. Następna strona Poprzednia strona Spis treści