head 1.1; access; symbols; locks; strict; comment @# @; 1.1 date 2002.12.25.23.21.59; author swiergot; state Exp; branches; next ; desc @@ 1.1 log @- Initial release. - Version 0.5.9. @ text @Aby pokazać, jak napisać skrypt .builder, użyję przykładu - skryptu mutt.builder, który buduje klienta pocztowego Mutt. Po zbudowaniu powinniśmy mieć cztery pakiety: główny pakiet z programem Mutt, pakiet zawierający instrukcję użytkownika w zwykłym tekscie, pakiet zawierający tą instrukcję w wersji HTML oraz pakiet z plikiem ChangeLog (jego rozmiar to ok. 400kB). Najpierw przygotujemy katalog na źródła i utworzymy plik .builder: # mkdir /usr/src/tgz/sources/mutt # touch /usr/src/tgz/sources/mutt/mutt.builder # chmod a+x /usr/src/tgz/sources/mutt/mutt.builder # echo "#!/bin/sh" > /usr/src/tgz/sources/mutt/mutt.builder Przekopiuj źródła Mutta do tego katalogu, np.: # cp mutt-1.4i.tar.gz /usr/src/tgz/sources/mutt Teraz uruchom swój ulubiony edytor tekstu i otwórz plik /usr/src/tgz/sources/mutt/mutt.builder. Zaczniemy pisać zaraz za "#!/bin/sh". Na początku musimy umieścić trochę zmiennych z kilkoma informacjami: name="mutt" title="Mutt" package="mutt" version="1.4i" build="1" noarch="n" build_info="" Rożnica między name i package jest taka, że name jest stała i określa co to jest, a package mówi jak zostało to zapakowane (z jakimi opcjami kompilacji itd.). Tutaj jest to tylko 'mutt', ale później mogą zostać dodane przyrostki. name i package nie mogą zawierać spacji, dużych liter, żadnych specjalnych znaków. title to pełna nazwa pakietu. Jeśli noarch jest ustawiona na 'y', znaczy to że pakiet nie zależy od architektury. Inaczej, będzie zbudowany na więcej procesorów (aktualnie tylko i386). build_info mówi w jaki sposób został ten pakiet zbudowany, jak package, lecz bardziej opisowo. Teraz jest puste, lecz ustawimy to później. Następne zmienne są opisami pakietu i kilkoma pomocnymi informacjami: info="A small but very powerful text-based mail client." desc="Mutt is a small but very powerful text-based MIME mail client. It is highly configurable, and is well-suited to the mail power user with advanced features like key bindings, keyboard macros, mail threading, regular expression searches, and a powerful pattern matching language for selecting groups of messages." category="net/client/email" environment="console/curses" contact="$name@@packages.packware.gnu.pl" vendor="Packware Project" vendor_id="pw" info to krótki opis na temat tego co ten pakiet robi (nie więcej niż 70 znaków). desc jest pełnym opisem. Możesz też napisać te dwie inforacje w innych językach, na przykład: info_pl="Mały, ale bardzo potężny tekstowy klient poczty." desc_pl="Mutt jest małym, ale bardzo potężnym tekstowym klientem poczty MIME. Jest wysoce konfigurowalny i nadaje się dla zaawansowanych użytkowników ze swoimi możliwościami, jak przypisywanie klawiszy, makra klawiatury, wątkowanie, wyszukiwanie z wyrażeniami regularnymi i potężnym językiem wzorów dopasowań do zaznaczania grup wiadomości." Tutaj te pola są po Polsku. Skrót od języka (pl) został dodany do nazwy zmiennej po znaku podkreślenia. category informuje o przeznaczeniu pakietu. environment mówi w jakim środowisku ten pakiet pracuje. Wysyłając wiadomość pod adres wymieniony w zmiennej contact, możesz skontaktować się z autorem pakietu. vendor mówi, kto (pojedyncza osoba lub cała grupa) zrobił pakiet. vendor_id to dwie lub trzy litery, które identyfikują twórcę. Będą użyte przy nadawaniu pakietowi nazwy: $package-$version-$architecture-$build$vendor_id.tgz. requires="" obsoletes="pine" conflicts="" Zmienna requires mówi o innych pakietach wymaganych przez nasz pakiet. Tutaj jest ona pusta, ponieważ Mutt nie potrzebuje żadnego. A zmienna ta nie dotyczy pakietów zawierających potrzebne biblioteki dynamiczne, jak ncurses z biblioteką libncurses.so w tym przypadku. Pakiety wymienione w obsoletes magą zostać zastąpione przez nasz pakiet. Zmienna conflicts mówi o pakietach, które nie mogą istnieć w systemie w tym samym czasie co nasz pakiet. docs_source="ABOUT-NLS,BEWARE,ChangeLog,COPYRIGHT,GPL,INSTALL,NEWS,README*" docs_cwd="" Zmienna docs_source zawiera nazwy plików z głównego katalogu źródeł, które zostaną umieszczone w /usr/doc/mutt-1.4i. Zmienna docs_cwd jest podobna, lecz pwbuilder będzie szukał tych plików w tym samym katalogu gdzie znajduje się mutt.builder. strip_bin="y" reset_own="y" reset_dir="y" reset_fil="y" delete_cat="y" strip_bin ustawione na 'y' powoduje usunięcie niepotrzebnych symboli z plików wykonywalych w pakiecie. reset_own ustawione na 'y' resetuje właścicieli plików i katalogów na root.root. Gdy reset_dir ma wartość 'y', wszystkie katalogi będą miały uprawnienia 755. Ustawienie reset_fil na 'y' spowoduje nadanie plikom praw 755 (wykonywalne) i 644 (inne). Jeśli delete_cat to 'y', pwbuilder usunie wszystkie sformatowane strony manuala z pakietu. Po tej części czas dołączyć plik definiujący funkcje i zmienne: . /usr/src/tgz/lib/builder.defs Ustawia on następujące zmienne: tmp (katalog tymczasowy), pkg_main (w tym katalogu pwbuilder umieści wszystkie pliki po kompilacji), src_pkg (katalog, który zawiera skrypt mutt.builder). Teraz musimy powiedzieć pwbuilderowi o źródłach. Użyjemy funkcji add_source: add_source $name-$version.tar.gz $name-`echo $version | cut -d i -f 1` Pierwszy argument to nazwa archiwum. Jeśli jest URL-em, źródło będzie pobrane z sieci, jeśli nie istnieje. Drugi to najwyższy katalog w archiwum. Jeśli jest pominięty, użyty zostanie domyślny, tzn. nazwa archiwum bez rozszerzenia. Zazwyczaj robimy 'tar zxf archive123.tar.gz' i 'cd archive123', ale archiwum z Muttem jest inne: 'tar zxf mutt-1.4i.tar.gz' i 'cd mutt-1.4' (bez 'i' po 1.4). To jest powód podawania argumentu do cd jako drugiego argumentu do add_source. Teraz mamy zmienną src1 ustawioną na nazwę katalogu z źródłami ($tmp/sources/mutt-1.4). Możemy dodać więcej źródeł tą funkcją i katalogi z nimi będą w zmiennych src2, src3 itd. Skrypt budujący może zapytać użytkownika o niektóre opcje kompilacji. Drukujemy pytanie funkcją verbose zamiast echo: verbose "Do you want mutt to support POP3 servers for retrieving mail?" Odczytujemy odpowiedź funkcją yes_or_no: yes_or_no with_pop3 y with_pop3 (pierwszy argument) to zmienna, która będzie ustawiona na 'y' lub 'n' w zależności od tego co powiedział użytkownik. Drugi argument (tutaj: 'y') to wartość domyślna. Nawet jeśli skrypt posiada instrukcje zadawające pytania, nadal jest możliwe wykonać skrypt bez żadnej interakcji. Wtedy zamiast pytania zmienna będzie ustawiona na tą domyślną wartość. Co możemy zrobić z odpowiedzią? Wszystko. Tutaj podamy parametr do skryptu ./configure: if [ "$with_pop3" = "y" ]; then configure_option --enable-pop build_info "With POP3. " else package_suffix nopop3 build_info "Without POP3. " fi Funkcja configure_option jest jasna, jak sądzę. Funkcja build_info dodaje tekst podany jako argument do zmiennej build_info. Funkcja package_suffix dodaje podany jako argument tekst do zmiennaj package. Jeśli ustawiliśmy tą zmienną na 'mutt', to teraz będzie to 'mutt-nopop3'. Użyjemy tych konstrukcji ponownie: verbose "Do you want mutt to support IMAP for storing and retrieving mail?" yes_or_no with_imap y if [ "$with_imap" = "y" ]; then configure_option --enable-imap build_info "With IMAP. " else package_suffix noimap build_info "Without IMAP. " fi if [ "$with_pop3" = "y" -o "$with_imap" = "y" ]; then verbose "Do you want mutt to support SSL connections to IMAP and/or POP3 servers?" yes_or_no with_ssl y if [ "$with_ssl" = "y" ]; then configure_option --with-ssl build_info "With SSL." else package_suffix nossl build_info "Without SSL." fi fi Teraz dodamy zawsze potrzebne opcje do ./configure: configure_option --prefix=/usr configure_option --sysconfdir=/etc/mutt configure_option --with-mailpath=/var/spool/mail configure_option --with-charmaps=/usr/share/i18n/charmaps configure_option --enable-locales-fix configure_option --with-docdir=/usr/doc/$name-$version Aby zainstalować pliki pod innym katalogiem (zmienna pkg_main) zamiast pod /, używamy zazwyczaj opcji DESTDIR podanej do 'make install'. Użyjemy do tego funkcji install_option: install_option DESTDIR=$pkg_main Jest również jeszcze funkcja make_option. Te trzy funkcje - configure_option, make_option i install_option - mogą brać również drugi argument. Jest nim numer źródeł, których dotyczą. Stąd instrukcja "configure_option --prefix=/usr 2" stosuje się do źródeł umieszczonych w katalogu wskazywanym przez zmienną src2. Dwie następne linie są stałe. Nie potrzebujesz wiedzieć co one robią. parent_package="$package" write_info main Zanim uruchomimy ./configure, 'make' i 'make install' (czy co tam buduje nasz program), musimy wejść do katalogu źródeł: cd $src1 Teraz możemy rozpocząć kompilację: do_configure do_make do_install Ach, mamy polką stronę manuala dla Mutta w tym samym katalogu co mutt.builder: mkdir -p $pkg_main/usr/man/pl/man1 cp $src_pkg/mutt.1.pl $pkg_main/usr/man/pl/man1/mutt.1 chmod 644 $pkg_main/usr/man/pl/man1/mutt.1 Teraz użyjemy funkcji make_docs do utworzenia katalogu /usr/doc/mutt-1.4i i skopiowania tam plików wymienionych w docs_source i docs_cwd: make_docs Tutaj jest właściwe miejsce do zdefiniowania podpakietów. Robimy następująco: subpackage manual subpackage manual-html subpackage changelog Oczywiście to nie wszystko. Powiem o tym później, a teraz będziemy kończyć nasz skrypt .builder. Wszystko co zostało to spakować pliki w pakiety: make_package main make_package manual make_package manual-html make_package changelog 'make_package main' odnosi się do głównego pakietu, czyli wszystkiego co zostało po wyłączeniu podpakietów. Inne dyrektywy make_package tworzą podpakiety. Po wszystkim dobrze jest usunąć pliki i katalogi tymczasowe: clean_up To wszystko. Teraz dokończymy definicje podpakietów. Jeśli piszemy 'subpackage some_name', to pwbuilder szuka pliku $src_pkg/package-info-some_name i $src_pkg/package-files-some_name. Pierwszy to mniej więcej to samo co pierwsze zmienne w mutt.builder (name, title, version itd.). Dla podpakietu changelog będzie to: name="mutt-changelog" title="Mutt's ChangeLog" package="mutt-changelog" noarch="y" build_info="" parent_package="mutt" info="The ChangeLog of the Mutt Mail User Agent." desc="This is the ChangeLog of the Mutt - simple but very powerful e-mail client." category="doc/user/changelog" environment="viewer/text" parent_package mówi o pakiecie z którego został wydzielony ten podpakiet. Moglibyśmy pominąć to i byłoby to 'mutt' z przyrostkami ustawionymi przez funkcję package_suffix, ale ChangeLog Mutta jest niezależny od opcji skryptu ./configure jak --with-pop czy --with-imap. To samo tyczy się zmiennej package - moglibyśmy napisać 'package="$parent_package-changelog"' ale nie zrobiliśmy tego. Wszystkie ustawione w mutt.builder, które nie zostały nadpisane w pliku package-info-changelog dostają wartości z pliku mutt.builder. Nie przytoczę plików package-info-manual i package-info-manual-html. Możesz zobaczyć je jakoże zostały załączone w pakiecie pwbuilder. Skąd pwbuilder wie, które pliki należą do podpakietu? Są kolejne pliki - package-files-some_name, np. package-files-changelog. W tym przypadku zawiera: usr/doc/mutt-$version/ChangeLog Zauważ że możesz użyć zmiennych ustawionych w pliku package-info-changelog lub w pliku mutt.builder jeśli nie zostały nadpisane. Co dalej? Myślę, że to wszystko. Wiesz wszystko, co jest potrzebne do napisania skryptu .builder. Jeśli masz jakieś pytania, zobacz FAQ. Jeśli nie znajdziesz tam odpowiedzi, nie wachaj się napisać do mnie. -- Jarosław Świerczyński @ .