Podręcznik dla nowych opiekunów pakietów Debiana ------------------------------------------------ Josip Rodin polskie tłumaczenie: Paweł Tęcza korekta tłumaczenia: Marcin Owsiany wersja oryginału: 1.2, 6 kwietnia 2002. wersja tłumaczenia: 1.2.2, 17 marca 2004 ------------------------------------------------------------------------------- Prawa autorskie --------------- Copyright (C) 1998-2002 Josip Rodin. Copyright (C) polskiego tłumaczenia 2002-2004 Paweł Tęcza, Marcin Owsiany. Ten dokument może być używany zgodnie z zasadami licencji GNU GPL (General Public License) w wersji 2 lub wyższej. Do stworzenia tego dokumentu wykorzystano, jako przykłady, następujące dokumenty: Making a Debian Package (znany jako Debmake Manual), copyright (C) 1997 Jaldhar Vyas. The New-Maintainer's Debian Packaging Howto, copyright (C) 1997 Will Lowe. ------------------------------------------------------------------------------- Spis treści ----------- 1. Rozpoczęcie tak, jak się należy 1.1. Programy, których potrzebujesz do rozwijania 1.2. Inne informacje 2. Pierwsze kroki 2.1. Wybierz swój program 2.2. Weź program i wypróbuj go 2.3. Nazwa pakietu i jego wersja 2.4. Wstępna "debianizacja" 3. Modyfikacja źródła 3.1. Instalacja w podkatalogu 3.2. Nie zgadzające się biblioteki 4. Rzeczy wymagane w katalogu debian/ 4.1. Plik `control' 4.2. Plik `copyright' 4.3. Plik `changelog' 4.4. Plik `rules' 5. Inne pliki z katalogu debian/ 5.1. Plik `README.Debian' 5.2. Plik `conffiles.ex' 5.3. Plik `cron.d.ex' 5.4. Plik `dirs' 5.5. Plik `docs' 5.6. Plik `emacsen-*.ex' 5.7. Plik `init.d.ex' 5.8. Pliki `manpage.1.ex', `manpage.sgml.ex' 5.9. Plik `menu.ex' 5.10. Plik `watch.ex' 5.11. Plik `ex.package.doc-base' 5.12. Pliki `postinst.ex', `preinst.ex', `postrm.ex', `prerm.ex' 6. Budowanie pakietu 6.1. Całkowita przebudowa 6.2. Szybka przebudowa 7. Sprawdzanie czy w pakiecie nie ma błędów 8. Umieszczanie pakietu w archiwum 9. Aktualizacja pakietu 9.1. Nowa poprawka Debiana 9.2. Nowe wydanie programu 9.3. Weryfikowanie uaktualnienia pakietu do nowszej wersji 10. Gdzie prosić o pomoc ------------------------------------------------------------------------------- 1. Rozpoczęcie tak, jak się należy ---------------------------------- Ten dokument próbuje opisać proces budowania pakietów dla systemu Debian GNU/Linux. Jest on przeznaczony dla zwykłych użytkowników Debiana i tych z nich, którzy chcą zostać rozwijającymi. Informacje w nim zawarte mogą służyć do budowania paczek ze źródeł napisanych w różnych popularnych językach programowania. Poparte one zostały praktycznymi przykładami, gdyż jak mówi stare rzymskie przysłowie, _Longum iter est per preaecepta, breve et efficax per exempla!_ (Droga według zasad jest długa, a z przykładami - krótka i wygodna!). Jedną z rzeczy czyniących z Debiana wyjątkową dystrybucję jest jego system pakietów. Mimo iż istnieje ogromna ilość oprogramowania spakowanego do formatu Debiana, to czasami zachodzi konieczność zainstalowania programu, który nie posiada odpowiedniej paczki. Pewnie się dziwisz, że możesz sam stworzyć własne pakiety i myślisz, że to bardzo trudne zadanie. No cóż, jeśli jesteś zupełnym nowicjuszem w Linuksie, to rzeczywiście będziesz miał kłopoty, ale czy gdybyś był żółtodziobem, to czytałbyś teraz ten dokument? :-) Musisz trochę wiedzieć na temat programowania pod Uniksem, ale nie musisz od razu być ekspertem. Jedna rzecz jest pewna: aby odpowiednio tworzyć i zarządzać pakietami Debiana potrzebne są osobogodziny. Staraj się nie popełniać błędów, gdyż nasz system do działania wymaga od opiekunów zarówno technicznej kompetencji jak i pilności. Ten dokument wyjaśni wszystkie kroki potrzebne do zbudowania pakietu (choć niektóre z nich mogą na początku wydać się nieistotne) i pomoże Ci stworzyć Twoją pierwszą paczkę. Dzięki niemu nabierzesz trochę doświadczenia, które przyda Ci się w trakcie budowania następnych wydań pakietu, a może również później do tworzenia innych paczek. Najnowsze wersje tego dokumentu powinny być zawsze dostępne bezpośrednio na stronie http://www.debian.org/doc/maint-guide/ (http://www.debian.org/doc/maint-guide) oraz w pakiecie ``maint-guide''. 1.1. Programy, których potrzebujesz do rozwijania ------------------------------------------------- Zanim zaczniesz cokolwiek robić, powinieneś upewnić się, że masz zainstalowanych kilka dodatkowych pakietów niezbędnych do rozwijania. Zwróć uwagę, że na poniższej liście nie ma żadnych pakietów oznaczonych jako `niezbędne' (essential) lub `wymagane' (required). Po prostu zakładamy, że masz już je zainstalowane. Ta wersja podręcznika została uaktualniona z myślą o pakietach wchodzących w skład Debiana 2.2 (`potato') oraz 3.0 (`woody'). Następujące pakiety wchodzą w skład standardowej instalacji Debiana więc prawdopodobnie masz je (i dodatkowe pakiety, od których one zależą) już zainstalowane. Mimo to powinieneś sprawdzić ich status za pomocą komendy `dpkg -s `. * `dpkg-dev' - pakiet zawierający narzędzia niezbędne do rozpakowywania, budowania i wysyłania pakietów źródłowych Debiana. (więcej informacji znajdziesz na stronie podręcznika dpkg-source(1)) * `file' - przydatny program do określania typu pliku. (więcej informacji znajdziesz na stronie podręcznika file(1)) * `gcc' - kompilator GNU języka C, niezbędny gdy Twój program tak jak większość programów zostało napisanych w języku C. (więcej informacji znajdziesz na stronie podręcznika gcc(1)). Pakiet ten jest powiązany z kilkoma innymi paczkami, takimi jak `binutils', która zawiera zestaw programów służący do asemblacji i konsolidacji plików wynikowych (więcej informacji znajdziesz za pomocą `info binutils` w pakiecie `binutils-doc') i `cpp', zawierającą preprocesor języka C. (więcej informacji znajdziesz na stronie podręcznika cpp(1)) * `g++' - kompilator GNU języka C++, niezbędny gdy Twój program został napisany w języku C++. (więcej informacji znajdziesz na stronie podręcznika g++(1)) * `libc6-dev' - biblioteki języka C i pliki nagłówkowe kompilatora gcc niezbędne do konsolidacji ze stworzonymi plikami wynikowymi. (więcej informacji znajdziesz za pomocą `info libc` w pakiecie `glibc-doc') * `make' - na ogół proces tworzenia programu składa się z kilku etapów. Zamiast ciągłego powtarzania w kółko tych samych komend, możesz posłużyć się programem, który zrobi to za Ciebie. Jedyne co musisz zrobić w tym celu, to stworzyć plik/pliki `Makefile'. (więcej informacji znajdziesz za pomocą `info make`) * `patch' - bardzo użyteczne narzędzie służące do nakładania na pliki źródłowe "łat", czyli stworzonych dzięki programowi diff plików z różnicami między plikami źródłowymi i tworzenia w ten sposób "załatanych" wersji programów. (więcej informacji znajdziesz na stronie podręcznika patch(1)) * `perl' - Perl jest jednym z najczęściej stosowanych interpretowanych języków skryptowych w systemach kompatybilnych z systemem Unix. Często określany jest jako "Uniksowy scyzoryk z piłą łańcuchową". (więcej informacji znajdziesz na stronie podręcznika perl(1)). Najprawdopodobniej będziesz chciał zainstalować również następujące pakiety: * `autoconf' i `automake' - wiele nowszych programów używa skryptów konfiguracyjnych i plików Makefile przetworzonych za pomocą takich narzędzi jak te. (więcej informacji znajdziesz za pomocą `info autoconf` i `info automake`) * `dh-make' i `debhelper' - pakiet dh-make jest niezbędny do stworzenia szablonu Twojego przykładowego pakietu. Używa on także do tworzenia pakietów niektórych narzędzi z pakietu debhelper. Pakiety te nie są niezbędne do budowania paczek, ale są _bardzo_ zalecane, szczególnie nowym opiekunom pakietów. Dzięki nim o wiele łatwiej rozpocząć proces budowania pakietu i kontrolować go później. (więcej informacji znajdziesz na stronach podręcznika dh_make(1), debhelper(1) oraz w pliku /usr/share/doc/debhelper/README). * `devscripts' - pakiet zawierający parę użytecznych i pomocnych dla opiekuna skryptów, które nie są jednakże niezbędne do budowania pakietów. (więcej informacji znajdziesz w pliku /usr/share/doc/devscripts/README.gz). * `fakeroot' - narzędzie, które pozwala Ci "udawać" bycie administratorem systemu. Uprawnienia administratora są niezbędne w niektórych etapach procesu budowania pakietu. (więcej informacji znajdziesz na stronie podręcznika fakeroot(1)) * `gnupg' - narzędzie umożliwiające Ci cyfrowe _podpisanie_ pakietu. Jest to szczególnie ważne, gdy zamierzasz rozpowszechniać swój pakiet wśród innych ludzi. Na pewno będziesz musiał to zrobić, gdy Twój pakiet zostanie włączony do dystrybucji Debiana. (więcej informacji znajdziesz na stronie podręcznika gpg(1)) * `g77' - kompilator GNU języka Fortran 77, niezbędny gdy Twój program został napisany w języku Fortran. (więcej informacji znajdziesz na stronie podręcznika g77(1)) * `gpc' - kompilator GNU języka Pascal, niezbędny gdy Twój program został napisany w języku Pascal. Warty odnotowania w tym miejscu jest również pakiet `fp-compiler' (Free Pascal Compiler), który także nadaje się do tego celu. (więcej informacji znajdziesz na stronach podręcznika gpc(1) i ppc386(1)) * `imake' i `xmkmf' - niektóre programy, głównie te stworzone z myślą o systemie X11, używają tych narzędzi do wygenerowania plików Makefile z zestawu makro-funkcji. (więcej informacji znajdziesz na stronach podręcznika imake(1) i xmkmf(1)) * `lintian' - program służący do sprawdzania poprawności pakietu Debiana. Poinformuje Cię on, gdy w zbudowanej paczce znajdzie najczęstsze błędy i wyjaśni ich przyczynę. (więcej informacji znajdziesz na stronie podręcznika lintian(1) oraz na stronie /usr/share/doc/lintian/lintian.html/index.html) Poniżej zamieszczono odnośniki do _bardzo ważnej_ dokumentacji, która powinna być przeczytana razem z tym podręcznikiem: * `debian-policy' - Polityka Debiana opisuje strukturę i zawartość archiwum Debiana, kilka spraw dotyczących projektu systemu operacyjnego, FHS (Standard Hierarchii Systemu Plików - Filesystem Hierarchy Standard), który mówi gdzie powinny się znajdować pliki i katalogi, itd. Najważniejszymi dla Ciebie rzeczami są opisane w Polityce wymagania, które musi spełnić każdy pakiet, aby mógł być włączony do dystrybucji. (więcej informacji znajdziesz na stronie /usr/share/doc/debian-policy/policy.html/index.html) * `developers-reference' - opisuje wszystkie zagadnienia nie związane z technicznymi szczegółami procesu tworzenia paczki, a więc strukturę archiwum, informacje na temat zmian nazw pakietów, ich osierocania i adopcji, informacje o tym, jak umieścić pakiet w archiwum Debiana, nie będąc opiekunem danego pakietu (Non-Maintainer Upload), jak radzić sobie z błędami, kiedy i gdzie umieszczać pakiet (więcej informacji znajdziesz na stronie /usr/share/doc/developers-reference/developers-reference.html/index.html). Powyższe krótkie opisy jedynie przedstawiają do czego służy dany pakiet. Zanim przejdziesz dalej, proszę gruntownie zapoznać się z dokumentacją do każdego z programów, a przynajmniej z ich standardowym użyciem. Być może wydaje Ci się to teraz męczące, ale później będziesz się _bardzo_ cieszyć, że to zrobiłeś/zrobiłaś. Uwaga: pakiet `debmake' zawiera kilka programów bardzo zbliżonych funkcjonalnie do pakietu _dh_make_, ale ten dokument _nie_ omawia jego użycia, ponieważ _odradza_ się jego używania. Po więcej informacji odsyłam na stronę the Debmake manual (http://www.debian.org/~jaldhar/). 1.2. Inne informacje -------------------- Istnieją dwa rodzaje pakietów jakie możesz stworzyć: źródłowe i binarne. Pakiet źródłowy zawiera kod, który możesz skompilować, aby otrzymać binarną postać programu. Pakiet binarny zawiera natomiast już gotowy do użycia program. Proszę nie mylić takich pojęć, jak źródło programu i pakiet źródłowy programu! Jeśli potrzebujesz więcej szczegółów na temat tej terminologii, to proszę przeczytać inne podręczniki. W Debianie, termin `opiekun' (maintainer) oznacza osobę, która tworzy pakiety i jest członkiem projektu Debian, `autor' (upstream author) - osobę, która tworzy program, a `zewnętrzny opiekun' (upstream maintainer) - osobę, która aktualnie opiekuje się programem, pozostając na zewnątrz projektu Debian. Zwykle autor i zewnętrzny opiekun są tą samą osobą, czasem nawet tą samą osobą co opiekun. Jeśli napisałeś jakiś program i chcesz, żeby wszedł w skład Debiana, to przyślij swoje podanie i zostań opiekunem. Gdy już zbudowałeś swój pakiet (lub gdy jesteś w trakcie jego budowania) i chcesz, aby Twój program wszedł w skład następnej dystrybucji (jeśli jest on użyteczny, to czemu nie?), to możesz zostać oficjalnym opiekunem pakietu Debiana. Proces przystępowania do projektu jest wyjaśniony w dokumencie Developer's Reference. Proszę przeczytać go. ------------------------------------------------------------------------------- 2. Pierwsze kroki ----------------- 2.1. Wybierz swój program ------------------------- Prawdopodobnie wybrałeś/wybrałaś już pakiet, który chcesz zbudować. Pierwszą rzeczą, którą powinieneś/powinnaś zrobić, to sprawdzić czy pakiet znajduje się już w dystrybucji. Jeśli używasz dystrybucji `stabilnej' (stable), to chyba najlepiej będzie, gdy udasz się na stronę z przeszukiwarką pakietów (http://www.debian.org/distrib/packages). Jeśli zaś używasz _aktualnej_ `niestabilnej' (unstable) dystrybucji, to sprawdź wynik działania poniższych komend: dpkg -s nazwa_programu dpkg -l '*nazwa_programu*' Jeśli pakiet już istnieje, to cóż, zainstaluj go! :-) Jeśli przypadkiem jest on osierocony (jego opiekunem jest "Debian QA Group"), to możesz się nim zaopiekować. Sprawdź na liście osieroconych pakietów (http://www.debian.org/devel/wnpp/orphaned) i liście pakietów przeznaczonych do adopcji (http://www.debian.org/devel/wnpp/rfa_bypackage) czy istotnie można przejąć opiekę nad tą paczką. Jeśli możesz zaadoptować pakiet, to pobierz jego źródła (za pomocą komendy `apt-get source nazwa_pakietu') i przetestuj go. Niestety ten dokument nie zawiera informacji na temat adopcji pakietów. Na szczęście nie powinieneś męczyć się rozpracowując działanie danego pakietu, gdyż ktoś już wcześniej dokonał wstępnych ustawień dla Ciebie. Dalsze czytanie poniższych porad będzie z pewnością odpowiednie również w Twoim przypadku. Jeśli pakiet jest nowy i chciałbyś, żeby został włączony do dystrybucji Debiana, to wykonaj poniższe instrukcje: * sprawdź na stronie lista pakietów będących w budowie (http://www.de.debian.org/devel/wnpp/being_packaged) czy ktoś już nie pracuje nad tym pakietem. Jeśli ktoś już to robi, to możesz się z nim skontaktować, gdy czujesz, że mógłbyś mu pomóc. W przeciwnym przypadku znajdź jakiś inny interesujący Cię program, który nie ma jeszcze swojego opiekuna. * program _musi_ mieć licencję, jeśli to możliwe, to najlepiej zgodną z Wytycznymi Debiana dotyczącymi Oprogramowania Wolnodostępnego (http://www.debian.org/social_contract.html#guidelines). Jeśli nie zgadza się ona z którymiś zasadami wymienionymi w powyższym dokumencie, to program może być włączony do sekcji `contrib' lub `non-free' Debiana. Gdy nie jesteś pewny, do której sekcji można włączyć program, to wyślij licencję tego programu na listę dyskusyjną i poproś o poradę. * program z pewnością _nie_ powinien być uruchamiany z ustanowionym identyfikatorem administratora systemu (set-user-ID root) - ogólnie program nie powinien potrzebować ustanowionego żadnego identyfikatora użytkownika (ang. set-user-ID) lub grupy (set-group-ID). * program nie powinien być demonem ani innym programem umieszczanym w katalogu */sbin, ani nie powinien otwierać portu jako administrator systemu. * program powinien mieć binarną, wykonywalną formę. Nie próbuj na tym etapie tworzyć pakietu z biblioteką, gdyż są one trudniejsze w budowaniu. * program lub przynajmniej jego kod źródłowy powinien być dobrze udokumentowany, albo łatwy do zrozumienia. * powinieneś skontaktować się z autorem/autorami programu, aby sprawdzić czy zgadzają się na jego zapakowanie. Ważną rzeczą jest możliwość konsultacji z autorem/autorami programu w razie wystąpienia jakichś problemów. Nie próbuj zatem pakować oprogramowania, którym się nikt nie opiekuje. * i na końcu, choć wcale nie jest to najmniej ważne, musisz wiedzieć jak program działa i wypróbować go przez pewien czas. Oczywiście powyższe rzeczy to po prostu środki zaradcze, które mają na celu uchronić Cię przed gniewem użytkowników, gdy zrobisz coś źle w jakimś demonie z ustanowionym identyfikatorem użytkownika... Gdy nabierzesz już więcej doświadczenia w pakowaniu, to zdołasz nawet zapakować takie programy, których powyżej Ci odradzałem. Jednakże nawet najbardziej doświadczeni rozwijający Debiana konsultują się na liście dyskusyjnej Mentorów Debiana (dostępnej pod adresem ), gdy mają jakieś wątpliwości, a ludzie do niej zasubskrybowani chętnie im pomagają. Więcej informacji na te tematy znajdziesz w dokumencie Developer's Reference. 2.2. Weź program i wypróbuj go ------------------------------ Pierwszą rzeczą, którą powinieneś zrobić, to odnalezienie i pobranie oryginalnego pakietu. Zakładam, że już masz plik źródłowy, który pobrałeś ze strony domowej jego autora. Źródła z wolnym oprogramowaniem dla Uniksa są zwykle rozprowadzane w formacie tar/gzip, czyli plikach z rozszerzeniem .tar.gz. Pliki te na ogół zawierają podkatalog o nazwie program-wersja, w którym znajdują się wszystkie pliki źródłowe. Jeśli źródła wybranego przez Ciebie programu są rozprowadzane w innym rodzaju archiwum (na przykład pliki kończące się na ".Z" lub ".zip"), to wypakuj je przy pomocy odpowiedniego narzędzia. Gdy nie jesteś pewien jak zrobić to poprawnie, to zapytaj na liście dyskusyjnej Mentorów Debiana (wskazówka: wydaj polecenie `file archiwum.rozszerzenie`). Dla przykładu, używam programu o nazwie `gentoo' - menadżera plików dla systemu X Window, który wykorzystuje bibliotekę GTK+. Zwróć uwagę, że program ten jest już zapakowany i znacznie się zmienił od czasu, gdy pisany był ten tekst. W swoim katalogu domowym stwórz podkatalog o nazwie 'debian', 'deb' lub jakkolwiek uważasz za właściwe (po prostu katalog ~/gentoo/ byłby w tym przypadku dobrym rozwiązaniem). Umieść w nim pobrane archiwum i rozkompresuj je (za pomocą komendy `tar xzf gentoo-0.9.12.tar.gz`). Upewnij się, że nie ma żadnych błędów, nawet jakichś nieistotnych, ponieważ najprawdopodobniej pojawią się problemy w czasie rozpakowywania w systemach innych ludzi, których narzędzia do wypakowywania mogą, ale nie muszą ignorować takich nieprawidłowości. Teraz w katalogu tym powinieneś mieć inny podkatalog o nazwie `gentoo-0.9.12'. Wejdź do niego i _dokładnie_ przeczytaj dostarczoną dokumentację. Zwykle powinny tam być pliki o nazwach README*, INSTALL*, *.lsm lub *.html. Odszukaj w dokumentacji instrukcji jak poprawnie skompilować i zainstalować program (najprawdopodobniej będą one zakładać, że chcesz zainstalować program do katalogu /usr/local/bin; ale Ty nie będziesz tego robić z powodów, których się dowiesz czytając sekcję Rozdział 3.1, `Instalacja w podkatalogu'). Proces instalacji różni się w zależności od programu, ale wiele nowoczesnych programów jest dostarczanych ze skryptem `configure', który konfiguruje źródła pod Twoim systemem i sprawdza czy spełniają one warunki niezbędne do poprawnej kompilacji. Po zakończeniu konfiguracji wykonywanej za pomocą polecenia `./configure`, programy są na ogół kompilowane przy użyciu komendy `make`. Niektóre z nich wspierają także komendę `make check`, która uruchamia procedurę samosprawdzającą. Instalacja w katalogu przeznaczenia następuje zwykle po wydaniu polecenia `make install`. Teraz spróbuj skompilować i uruchomić program, aby upewnić się czy działa on prawidłowo i nic się nie psuje w czasie instalacji lub wykonywania. Możesz też zazwyczaj użyć polecenia `make clean` (lub lepiej `make distclean`), aby posprzątać po zbudowanym katalogu. Czasem można nawet posłużyć się poleceniem `make uninstall`, które usunie wszystkie zainstalowane pliki. 2.3. Nazwa pakietu i jego wersja -------------------------------- Powinieneś/powinnaś rozpocząć pakowanie z zupełnie wyczyszczonym (ang. pristine - pierwotnym) katalogiem źródłowym, ewentualnie ze świeżo rozpakowanymi źródłami. Aby prawidłowo zbudować pakiet, musisz tak zmienić nazwę oryginalnego programu, żeby występowały w niej tylko małe litery (o ile występują tam jakieś wielkie litery). Powinieneś także przenieść katalog ze źródłami do katalogu -. Jeśli nazwa programu składa się z więcej niż jednego wyrazu, to obetnij ją do jednego wyrazu albo utwórz skrót, na przykład pakiet z programem "John's little editor for X" powinien się nazywać johnledx, jle4x lub tak jak zdecydujesz. Pamiętaj jednak, aby jego długość nie przekraczała jakiejś rozsądnej wartości, dla przykładu 20 znaków. Sprawdź także dokładnie wersję programu (będzie ona włączona do nazwy pakietu). Jeśli do oznaczenia jego wersji autor nie użył konwencji X.Y.Z, ale, dla przykładu, posłużył się datą, to Ty również możesz jej użyć do określenia wersji pakietu (poprzedź ją ciągiem "0.0.", na wypadek gdyby autor programu zdecydował się kiedyś wydać wersję o miło brzmiącym numerze 1.0). Zatem, jeśli datą wydania danej wersji programu było 19 grudnia 1998 r., to powinieneś oznaczyć jego wersję jako 0.0.19981219. Niektóre programy nie są jednak w żaden sposób numerowane. W takich przypadkach powinieneś skontaktować się z nieoficjalnym opiekunem, aby dowiedzieć się czy używa on jakiejś innej metody do oznaczania kolejnych poprawek programu. 2.4. Wstępna "debianizacja" --------------------------- Upewnij się, że jesteś w katalogu ze źródłami programu i wydaj następującą komendę: dh_make -e twój_adres@e-mail -f ../gentoo-0.9.12.tar.gz Oczywiście musisz zastąpić ciąg "twój_adres@e-mail" adresem Twojej skrzynki pocztowej, gdyż zostanie on wpisany do pliku ze zmianami (`changelog') i jeszcze innych plików. Musisz również zastąpić nazwę pliku nazwą Twojego oryginalnego archiwum źródłowego. Więcej szczegółów znajdziesz na stronie podręcznika dh_make(1). Będziesz musiał/musiała też wprowadzić kilka dodatkowych informacji. Zostaniesz poproszony/poproszona o podanie typu archiwum jakie tworzysz. Gentoo to pojedynczy pakiet binarny - tworzy on tylko jeden plik binarny, a zatem jeden plik .deb. W takim wypadku zaznaczamy pierwszą opcję za pomocą klawisza `s'. Następnie sprawdzamy informacje na ekranie i jeśli się wszystko zgadza, to potwierdzamy je naciskając . Ponieważ jesteś jeszcze nowym opiekunem, to odradzam Ci tworzenie pakietów z wieloma pakietami binarnymi lub bibliotekami. Budowanie ich nie jest wcale takie trudne, ale wymaga trochę większej wiedzy, zatem nie będziemy tutaj wszystkiego opisywać. Proszę zauważyć, że powinno się uruchomić program dh_make _tylko jeden raz_, gdyż nie zachowa się on poprawnie, gdy uruchomisz go ponownie w tym samym, już "zdebianizowanym" katalogu. Oznacza to również, że będziesz musiał użyć innej metody, aby zrealizować w przyszłości nową poprawkę lub nową wersję pakietu. Więcej informacji na ten temat znajdziesz później w sekcji Część 9, `Aktualizacja pakietu'. ------------------------------------------------------------------------------- 3. Modyfikacja źródła --------------------- Normalnie, programy instalują się same w podkatalogach katalogu /usr/local. Pakiety Debiana nie mogą jednak używać tego katalogu, gdyż jest on zarezerwowany do prywatnego użycia przez administratora (lub użytkownika) systemu. Oznacza to, że musisz się przyjrzeć jak budowany jest Twój program, zwykle za pomocą pliku Makefile. Jest to skrypt programu make(1) używanego do automatycznego budowania programu. Więcej szczegółów na temat plików Makefile znajdziesz w sekcji Rozdział 4.4, `Plik `rules''. Zwróć też uwagę na to czy Twój program używa programów GNU automake(1) i/lub autoconf(1). Oznacza to, że źródła programu zawierają plik Makefile.am i/lub Makefile.in i że to je będziesz musiał wtedy modyfikować. Dzieje się tak, ponieważ każde wywołanie programu automake powoduje ponowne utworzenie pliku Makefile.in z informacjami wygenerowanymi z pliku Makefile.am. Także każde wywołanie skryptu ./configure zrobi to samo z plikiem Makefile, a dane będą pochodzić z pliku Makefile.in. Edycja plików Makefile.am wymaga pewnej wiedzy na temat programu automake, możesz o nim poczytać za pomocą komendy `info automake'. Edytowanie plików Makefile.in odbywa się niemal tak samo jak w przypadku plików Makefile, po prostu zwracasz uwagę na zmienne, tzn. wszystkie łańcuchy otoczone przez znaki `@', dla przykładu zmienna @CFLAGS@ lub @LN_S@ będzie zastępowana odpowiednią wartością przy każdym wywołaniu skryptu ./configure. Zauważ również, że nie ma tu wystarczającego miejsca, aby opisać _wszystkie_ szczegóły na temat poprawiania zewnętrznych źródeł. Przedstawiamy tu jedynie kilka problemów, na które ludzie często się natykają. 3.1. Instalacja w podkatalogu ----------------------------- Wiekszość programów posiada swój własny sposób instalowania się w istniejącej strukturze katalogów Twojego systemu. Ścieżki do ich plików binarnych trafiają do katalogów w Twojej zmiennej środowiskowej $PATH, zaś dokumentacja do programu i strony podręcznika są umieszczane w powszechnie stosowanych miejscach. Jednakże, jeśli pozwolisz na takie działanie, to program może się zainstalować w każdym miejscu Twojego systemu. Może sprawić to problemy narzędziom do obsługi pakietów, gdyż nie będą one wiedziały, które pliki należą do Twojej paczki, a które nie. Zatem musisz zrobić coś innego: zainstalować swój program w tymczasowym katalogu, z którego narzędzia opiekuna zbudują działający pakiet .deb. Wszystko co zawiera ten katalog zostanie zainstalowane w systemie użytkowników, gdy zdecydują się oni zainstalować Twoją paczkę, z tą tylko różnicą, że program dpkg zainstaluje pliki względem katalogu głównego systemu. Ten tymczasowy katalog jest zazwyczaj tworzony wewnątrz Twojego katalogu debian/ w rozpakowanym drzewie ze źródłami. Na ogół ma on nazwę `debian/tmp' lub `debian/nazwa_pakietu'. Pamiętaj, że nie wystarczy żeby program zachowywał się poprawnie, gdy zostanie on zainstalowany się w katalogu debian/nazwa_pakietu. Musi on zachowywać się właściwie także, gdy zostanie umieszczony w głównym katalogu systemu. Zatem nie wolno pozwolić, żeby w plikach pakietu zostały "zaszyte" takie ścieżki jak `/home/ja/deb/gentoo-0.9.12/usr/share/gentoo'. Sprawa jest zupełnie prosta, gdy programy używają narzędzia GNU autoconf. Większość z nich posiada pliki Makefile, które domyślnie są ustawione w taki sposób, aby zezwalać na instalację w dowolnym podkatalogu zakładając, że katalog /usr (dla przykładu) jest kanonicznym prefiksem. Gdy zostanie wykryte, że Twój program używa programu autoconfa, to dh_make ustawi odpowiednie komendy tak, żeby wszystko zostało zrobione automatycznie. W takich przypadkach możesz nawet ominąć dalsze czytanie tej sekcji. Z innymi programami będziesz miał więcej pracy i prawdopodobnie będziesz musiał przejrzeć i wyedytować pliki Makefile. Poniżej znajduje się odpowiednia część pliku Makefile programu gentoo. # Where to put binary on 'make install'? BIN = /usr/local/bin # Where to put icons on 'make install'? ICONS = /usr/local/share/gentoo Widzimy, że pliki te zostaną zainstalowane wewnątrz katalogu `/usr/local'. Zmieńmy zatem ścieżki na następujące: # Where to put binary on 'make install'? BIN = $(DESTDIR)/usr/bin # Where to put icons on 'make install'? ICONS = $(DESTDIR)/usr/share/gentoo Ale dlaczego właśnie w tym katalogu, a nie w jakimś innym? Ponieważ pakiety Debiana nigdy nie instalują plików w katalogu `/usr/local'. Ten katalog jest zarezerwowany na potrzeby administratora systemu. W systemie Debian zaś takie pliki trafiają do katalogu `/usr'. Dokładniejsze informacje na temat położenia binariów, ikon, dokumentacji, itd. są opisane w dokumencie Filesystem Hierarchy Standard (zobacz do katalogu /usr/share/doc/debian-policy/fhs/). Polecam Ci przejrzenie tego dokumentu i przeczytanie tych sekcji, które mogą dotyczyć Twojego pakietu. Zatem powinniśmy instalować pliki binarne w katalogu /usr/bin, a nie w /usr/local/bin, strony podręcznika w katalogu /usr/share/man/man1, a nie w /usr/local/man/man1, itd. Zauważ, że w pliku Makefile programu gentoo nie wspomniano o jego stronie podręcznika, ale ponieważ Polityka Debiana wymaga, żeby każdy program posiadał taką stronę, to stworzymy ja później i zainstalujemy w katalogu /usr/share/man/man1. Niektóre programy nie używają zmiennych w plikach Makefile do definiowania ścieżek takich jak te powyżej. Oznacza to, że będziesz musiał wyedytować niektóre źródła napisane w języku C i tak je poprawić, aby używały właściwych położeń. Ale gdzie i czego właściwie szukać? Możesz to odnaleźć wydając polecenie: grep -rn usr/local/lib *.[ch] Program grep przeszuka rekursywnie całe drzewo ze źródłami i wypisze dla Ciebie nazwy plików i numery linii w nich, gdy odnajdzie szukany wzorzec. Teraz wyedytuj te pliki, w odnalezionych liniach zastąp ciąg /usr/local/* ciągiem usr/* i to już wszystko. Zrób to bardzo ostrożnie, aby nie zepsuć pozostałej części kodu! :-) Następnie powinieneś/powinnaś odnaleźć w pliku Makefile cel `install' (szukając linii rozpoczynającej się od ciągu "install:') i zmienić nazwę wszystkich odniesień do katalogów innych niż te zdefiniowane na początku pliku Makefile. Przed zmianą, cel `install' programu gentoo był następujący: install: gentoo install ./gentoo $(BIN) install icons/* $(ICONS) install gentoorc-example $(HOME)/.gentoorc Po wykonaniu zmian wygląda on następująco: install: gentoo-target install -d $(BIN) $(ICONS) $(DESTDIR)/etc install ./gentoo $(BIN) install -m644 icons/* $(ICONS) install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc Pewnie zauważyłeś/zauważyłaś, że teraz przed pozostałymi komendami w tej regule będzie wykonywana komenda `install -d'. Oryginalny plik Makefile nie miał jej, gdyż zwykle katalog /usr/local/bin i inne katalogi istnieją już w systemie zanim wyda się polecenie `make install`. Jednakże, gdy zainstalujemy program do Twojego własnego, pustego (lub nawet nie istniejącego) katalogu, to będziemy musieli stworzyć każdy z tych katalogów. Możemy również dodać inne rzeczy na końcu tej reguły, na przykład dodatkową dokumentację, którą autor programu czasem pomija. install -d $(DESTDIR)/usr/share/doc/gentoo/html cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html Uważny czytelnik zauważy, że zmieniłem `gentoo' na `gentoo-target' w linii rozpoczynającej się od ciągu `install:'. To jest tzw. naprawa błędu :-) Ilekroć dokonasz zmian, które nie są ściśle związane z pakietem Debiana, upewnij się, że poinformowałeś o nich autora programu, aby mógł on je włączyć do następnej poprawki programu i by również ktoś inny mógł z nich skorzystać. Pamiętaj także, żeby tworzyć poprawki nie specyficzne dla Debiana, Linuksa (lub nawet Uniksa!) przed ich wysłaniem -- niech będą one przenośne. Dzięki temu Twoje łaty będzie łatwiej nałożyć. Zauważ, że nie musisz wysyłać autorowi programu plików debian/*. 3.2. Nie zgadzające się biblioteki ---------------------------------- Tutaj mamy pewien dość powszechny problem: biblioteki często różnią się pomiędzy platformami, na których działają. Dla przykładu, plik Makefile może zawierać odwołania do biblioteki, której nie ma Debianie. W takim przypadku musimy zmienić ją na bibliotekę, która jest dostępna pod Debianem i służy tym samym celom. Jeśli zatem w pliku Makefile (lub Makefile.in) Twojego programu istnieje linia podobna do tej poniżej (i Twój program nie chce się skompilować): LIBS = -lcurses -lcoś -lcoś_innego to zmień ją w pokazany sposób i to powinno prawdopodobnie pomóc: LIBS = -lncurses -lcoś -lcoś_innego (Autor zdaje sobie sprawę, że to nie jest najlepszy przykład, zważywszy na to, że pakiet libncurses jest teraz dostarczany wraz z dowiązaniem symbolicznym do biblioteki współdzielonej libcurses.so, ale nie mógł on wymyślić niczego lepszego. Sugestie będą bardzo mile widziane :-)) ------------------------------------------------------------------------------- 4. Rzeczy wymagane w katalogu debian/ ------------------------------------- W katalogu ze źródłami Twojego programu istnieje nowy podkatalog, który nazywa się `debian'. Zawiera on kilka plików, które będziemy edytować, aby dopasować działanie pakietu. Najważniejszymi z nich są pliki `control', `changelog', `copyright' i 'rules', które są wymagane w każdym pakiecie. 4.1. Plik `control' ------------------- Ten plik zawiera różne informacje, których używaja programy `dpkg' i `dselect' oraz inne narzędzia służące do zarządzania pakietem. Poniżej przedstawiono plik control stworzony dla nas przez program dh_make. 1 Source: gentoo 2 Section: unknown 3 Priority: optional 4 Maintainer: Josip Rodin 5 Build-Depends: debhelper (>> 3.0.0) 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Description: 12 (Numery linii zostały dodane przeze mnie) Linie 1-6 zawierają informacje kontrolne dla pakietu źródłowego. Linia nr 1 zawiera nazwę pakietu źródłowego. Linia nr 2 oznacza sekcję dystrybucji, do której należy pakiet. Być może zauważyłeś już, że Debian jest podzielony na następujące sekcje: `main' (zawiera wolne oprogramowanie), `non-free' (zawiera oprogramowanie, które nie jest wolne) i `contrib' (zawiera wolne oprogramowanie, które wymaga oprogramowania, które nie jest wolne). Dodatkowo każda z sekcji dzieli się na logiczne podsekcje, które w skrócie mówią, do czego służy dany pakiet. Mamy zatem sekcję `admin', która zawiera programy przeznaczone tylko dla administratora systemu, `base' z podstawowymi narzędziami, `devel' z narzędziami dla programistów, `doc' z dokumentacją, `libs' z bibliotekami, `mail' z programami do wysyłania/odbierania poczty elektronicznej i z demonami pocztowymi, `net' z aplikacjami sieciowymi i demonami usług sieciowych, `x11' z programami dla systemu X11, które nie pasują nigdzie indziej i wiele innych sekcji. Zmieńmy ją zatem na x11. (Prefiks "main/" jest przyjmowany domyślnie, więc możemy go pominąć) Linia nr 3 opisuje jak ważne jest to, aby użytkownik zainstalował dany pakiet. Więcej informacji na temat wartości jakie może przyjmować te pole znajdziesz w podręczniku Polityki Debiana. Dla nowych pakietów zazwyczaj może ono przyjmować wartość "optional". Sekcja (Section) i priorytet (Priority) są używane przez takie nakładki jak program dselect, które używają ich do sortowania pakietów i wyboru domyślnego zestawu pakietów do zainstalowania. Gdy będziesz umieszczał swój pakiet w archiwum Debiana, to wartość tych dwóch pól może być nadpisana przez opiekunów archiwum FTP. W takich przypadkach zostaniesz o tym powiadomiony e-mailem. Ponieważ jest to pakiet o normalnym priorytecie, to pozostawiamy tam wartość "optional". Linia nr 4 zawiera imię i nazwisko oraz adres e-mail opiekuna pakietu. Upewnij się, że pole te zawiera wartość odpowiednią dla nagłówka "To:", gdyż po umieszczeniu pakietu w archiwum, system śledzenia błędów użyje tego pola do wysyłania Ci e-maili ze zgłoszeniami błędów. Unikaj stosowania przecinków, ampersandów (`&') i nawiasów. Linia nr 5 zawiera listę pakietów wymaganych do zbudowania Twojego pakietu. Niektóre pakiety, na przykład gcc i make są założone z góry, więcej szczegółów na temat znajdziesz w pakiecie `build-essential'. Jeśli do zbudowania Twojego pakietu jest potrzebny jakiś niestandardowy kompilator lub inne narzędzie, to powinieneś dodać tutaj linię `Build-Depends'. Wpisy w tej linii są oddzielone od siebie za pomocą przecinków; poczytaj na temat zależności binariów, aby dowiedzieć się więcej na temat składni tego pola. Możesz także użyć w tym miejscu takich pól jak Build-Depends-Indep, Build-Conflicts i innych. Dane te są używane przez oprogramowanie do automatycznego budowania pakietów w celu stworzenia pakietów przeznaczonych dla różnych platform komputerowych. Więcej informacji na temat zależności w trakcie budowania pakietu znajdziesz w podręczniku Polityki. Dokument Developers' Reference zawiera więcej szczegółów na temat innych platform (architektur) oraz adaptowania (ang. porting) do nich oprogramowania. Poniżej pokazano sztuczkę, dzięki której odszukasz paczki, których potrzebuje do zbudowania Twój pakiet: strace -f -o /tmp/log ./configure # or make instead of ./configure, if the package doesn't use autoconf for x in `dpkg -S $(grep open /tmp/log|perl -pe 's!.* open\(\"([^\"]*).*!$1!' |grep "^/"| sort | uniq| grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|cut -f1 -d":"| sort | uniq`; do echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; done Program gentoo wymaga do zbudowania pakietów `xlibs-dev', `libgtk1.2-dev' i `libglib1.2-dev', więc dodajmy je tutaj, aby wykorzystał je `debhelper'. Linia nr 6 zawiera wersję standardów polityki Debiana, którą dany pakiet spełnia, wersję podręcznika Polityki, który czytasz w trakcie tworzenia Twojego pakietu. Linia nr 8 to nazwa pakietu binarnego. Zwykle jest ona taka sama jak nazwa pakietu źródłowego, ale to nie jest regułą. Linia nr 9 opisuje architekturę procesora, dla którego może być skompilowany pakiet. Pozostawimy w niej "any", gdyż pakiet dpkg-gencontrol(1) sam wstawi w tym miejscu odpowiednią wartość dla każdego typu maszyny, na której kompilowany jest pakiet. Jeśli Twój pakiet jest niezależny od architektury procesora (dla przykładu skrypt powłoki lub Perla, albo jakiś dokument), to wpisz tutaj "all" i poczytaj później w sekcji Rozdział 4.4, `Plik `rules'' na temat używania reguły `binary-indep' zamiast `binary-arch' do budowania pakietu. Linia nr 10 pokazuje jedną z najpotężniejszych cech systemu pakietów Debiana. Pakiety mogą znajdować się w różnych relacjach z innymi pakietami. Oprócz pola Depends: mogą też występować pola opisujące inne związki: Recommends:, Suggests:, Pre-Depends:, Conflicts:, Provides: i Replaces:. Narzędzia do zarządzania pakietami zwykle zachowują się w ten sam sposób w czasie ustalania stosunków między pakietami. Jeśli tak nie jest, to zostanie to wkrótce wyjaśnione (więcej informacji znajdziesz na stronach podręcznika dpkg(8), dselect(8), apt(8), aptitude(1), itd.) Pola te oznaczają: * Depends: (Wymaga) Pakiet nie zostanie zainstalowany o ile pakiety, których on wymaga nie są już zainstalowane w systemie. Użyj tego pola, gdy Twój program absolutnie nie może być uruchomiony (lub spowoduje poważne szkody), jeśli jakiś szczególny pakiet nie jest jeszcze obecny w systemie. * Recommends: (Zaleca) Nakładki takie jak dselect czy aptitude zachęcą Cię do zainstalowania zalecanych pakietów wraz z Twoim pakietem; dselect będzie nawet na to nalegać. Programy dpkg i apt-get jednakże zignorują te pole. Użyj tego pola dla pakietów, które nie są niezbędne, ale są zwykle używane razem z Twoim programem. * Suggests: (Poleca) Gdy użytkownik instaluje Twój program, wszystkie nakładki zachęcą go także do zainstalowania pakietów, które on poleca. Programy dpkg i apt-get nie powinny się o nie troszczyć. Użyj tego pola dla pakietów, które będą dobrze działać z Twoim programem, ale nie są dla niego niezbędne. * Pre-Depends: (Przed-Wymaga) Jest to silniejsza relacja niż Depends:. Pakiet nie zostanie zainstalowany o ile pakiety, od których jest on przed-zależny nie są zainstalowane w systemie i _poprawnie skonfigurowane_. Używaj tego pola _bardzo_ oszczędnie i jedynie po przedyskutowaniu tego na liście debian-devel. Czytaj: nie używaj go nigdy. :-) * Conflicts: (PowodujeKonflikt) Pakiet nie zostanie zainstalowany dopóki wszystkie pakiety, które powodują konflikt nie zostaną wcześniej usunięte z systemu. Użyj tego pola, gdy Twój program absolutnie nie może być uruchomiony lub spowoduje jakieś problemy, jeśli jakiś szczególny pakiet jest wciąż obecny w systemie. * Provides: (Dostarcza) Dla niektórych rodzajów pakietów zostało zdefiniowanych wiele alternatywnych nazw wirtualnych. Pełną listę tych pakietów znajdziesz w pliku /usr/share/doc/debian-policy/virtual-package-names-list.txt.gz. Użyj tego pola, jeśli Twój program dostarcza funkcjonalności istniejącego już pakietu wirtualnego. * Replaces: (Zastępuje) Użyj tego pola, gdy Twój program zastępuje pliki jakiegoś innego pakietu lub zupełnie zastępuje jakiś pakiet (używane łącznie z polem Conflicts:). Pliki z wymienionych pakietów zostaną nadpisane przez pliki z Twojego pakietu. Wszystkie te pola mają jednolitą składnię. Jest to lista nazw pakietów oddzielonych za pomocą przecinka. Nazwy pakietów mogą również być listami alternatywnych nazw pakietów odseparowanych przy pomocy symbolu `|' (symbol potoku). Pola mogą ograniczać swoje zastosowanie tylko do szczególnych wersji każdego wymienionego pakietu. Wersje te są umieszczone w nawiasach po każdej nazwie pakietu i powinny zawierać relacje między numerami wersji pakietów. Dozwolonymi relacjami są: `<<', `<=', `=', `>=' i `>>' i odpowiednio oznaczają: wcześniejszy, wcześniejszy lub równy, dokładnie równy, późniejszy lub równy i późniejszy. Dla przykładu: Depends: foo (>= 1.2), libbar1 (= 1.3.4) Conflicts: baz Recommends: libbaz4 (>> 4.0.7) Suggests: quux Replaces: quux (<< 5), quux-foo (<= 7.6) Ostatnią cechą, o której powinieneś/powinnaś wiedzieć jest ${shlibs:Depends}. Gdy Twój pakiet zostanie zbudowany i zainstalowany w tymczasowym katalogu, program dh_shlibdeps(1) "prześwietli" go w poszukiwaniu binariów i bibliotek, określi jakich bibliotek współdzielonych on wymaga i wykryje, w których pakietach się one znajdują, na przykład libc6 lub xlib6g. Następnie program dh_gencontrol(1) umieści ich nazwy we właściwym miejscu, więc nie musisz się o to martwić. Skoro już wszystko zostało powiedziane, to możemy pozostawić linie nr 10 w takiej postaci jak teraz i wstawić po niej inną (`Suggests: file'), która będzie mówiła o pakiecie, które program gentoo sugeruje, ponieważ może on użyć niektórych funkcjonalności dostarczanych przez ten program/pakiet. Linia nr 11 zawiera krótki opis pakietu. Ekrany większości ludzi mają szerokość 80 kolumn, więc nie powinna ona zawierać więcej niż 60 znaków. Ja wpisałem w niej "A fully GUI configurable X file manager using GTK+". Od linii nr 12 zaczyna się dłuższy opis pakietu. Powinien to być paragraf dostarczający więcej szczegółów na temat pakietu. Kolumna nr 1 każdej linii długiego opisu powinna być pusta. Ponieważ opis ten nie może zawierać pustych linii, to wszędzie tam gdzie chciałbyś je wstawić musisz umieścić znak . (kropka) w kolumnie nr 2. Także na końcu długiego opisu nie może się pojawić więcej niż jedna pusta linia. A oto końcowa postać uaktualnionego pliku `control': 1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin 5 Build-Depends: debhelper (>> 3.0.0), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Suggests: file 12 Description: A fully GUI configurable X file manager using GTK+ 13 gentoo is a file manager for Linux written from scratch in pure C. It 14 uses the GTK+ toolkit for all of its interface needs. gentoo provides 15 100% GUI configurability; no need to edit config files by hand and re- 16 start the program. gentoo supports identifying the type of various 17 files (using extension, regular expressions, or the 'file' command), 18 and can display files of different types with different colors and icons. 9 . 20 gentoo borrows some of its look and feel from the classic Amiga file 21 manager "Directory OPUS" (written by Jonathan Potter). (Numery linii zostały dodane przeze mnie) 4.2. Plik `copyright' --------------------- Plik ten zawiera informacje o zewnętrznych zasobach pakietu, prawach autorskich i licencji. Jego format nie jest narzucony przez Politykę Debiana, ale jego zawartość już tak (zobacz sekcję 13.6 "Informacje o prawach autorskich"). Program dh_make stworzył już taki domyślny plik, którego zawartość jest podobna do tej poniżej: 1 This package was debianized by Josip Rodin on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from 5 6 Upstream Author(s): 7 8 Copyright: 9 10 (Numery linii zostały dodane przeze mnie) Ważnymi rzeczami, które powinieneś dodać do tego pliku jest miejsce, z którego pobrałeś pakiet ze źródłami oraz informacje o prawach autorskich i licencji. Musisz dołączyć kompletną treść licencji, chyba że jest to jedna z popularnych licencji wolnego oprogramowania, takich jak GNU GPL i LGPL, BSD lub licencja Artystyczna. W takiej sytuacji możesz po prostu odesłać do odpowiedniego pliku w katalogu /usr/share/common-licenses/, który występuje w każdym systemie Debian. Poniżej pokazano w skrócie jak powinien wyglądać plik `control' dla programu gentoo: 1 This package was debianized by Josip Rodin on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from: ftp://ftp.obsession.se/gentoo/ 5 6 Upstream author: Emil Brink 7 8 This software is copyright (c) 1998-99 by Emil Brink, Obsession 9 Development. 10 11 You are free to distribute this software under the terms of 12 the GNU General Public License. 13 On Debian systems, the complete text of the GNU General Public 14 License can be found in the file `/usr/share/common-licenses/GPL'. (Numery linii zostały dodane przeze mnie) 4.3. Plik `changelog' --------------------- Obecność tego pliku jest wymagana. Jego specjalny format opisano w Polityce Debiana (sekcja 5.3 "debian/changelog"). Format ten jest wykorzystywany przez dpkg i inne programy do uzyskiwania informacji o numerze wersji, poprawce, dystrybucji i pilności Twojego pakietu. Jest on także ważny dla Ciebie, ponieważ dobrze jest mieć udokumentowane wszystkie zmiany, których dokonałeś. Pomaga to ludziom pobierającym Twój pakiet zorientować się czy nie zrobiłeś z pakietem czegoś, o czym powinni oni wiedzieć. Zmiany te zostaną zapisane do pliku `/usr/share/doc/gentoo/changelog.Debian.gz' w pakiecie binarnym. Program dh_make również tworzy taki plik, którego zawartość wygląda mniej więcej tak: 1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 5 -- Josip Rodin Wed, 11 Nov 1998 21:02:14 +0100 (Numery linii zostały dodane przeze mnie) Linia nr 1 zawiera nazwę pakietu, jego wersję, dystrybucję i pilność. Nazwa musi się zgadzać z nazwą pakietu źródłowego, dystrybucja powinna mieć wartość albo `unstable' (albo nawet `experimental'), zaś pilności nie powinieneś zmieniać na wartość większą niż `low' (niska). :-) Linie 3-5 to dziennik, w którym dokumentujesz zmiany dokonane w poprawce pakietu (ale nie zmiany zewnętrzne - do tego celu służy specjalny plik stworzony przez autorów programu, który później zainstalujesz jako /usr/share/doc/gentoo/changelog.gz). Nowe linie muszą być umieszczone przed znajdującą się na górze linią, która rozpoczyna się od gwiazdki (`*'). Możesz to zrobić przy pomocy dch(1) lub używając jakiegoś edytora tekstu. Zakończ ten plik podobnie jak poniżej: 1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $DESTDIR problems. 6 7 -- Josip Rodin Wed, 11 Nov 1998 21:02:14 +0100 8 (Numery linii zostały dodane przeze mnie) Więcej na temat pliku `changelog' bedziesz mógł przeczytać później w sekcji Część 9, `Aktualizacja pakietu'. 4.4. Plik `rules' ----------------- Teraz musimy się przyjrzeć regułom, których użyje program dpkg-buildpackage(1) do stworzenia pakietu. Plikiem tym jest obecnie Makefile, lecz inny niż ten/te znajdujący/znajdujące się w źródłach programu. W odróżnieniu od innych plików znajdujących się w katalogu debian/ ma on ustawiony atrybut wykonywalności. Każdy plik `rules', tak samo jak plik Makefile, zawiera różne reguły, które wyszczególniają jak postępować ze źródłem. Każda reguła z kolei zawiera cele (targets), czyli nazwy plików bądź akcji, które powinny być stworzone lub wykonane (na przykład `build:' lub `install:'). Reguły, które chcesz wykonać są wywoływane z linii komend jako argumenty poleceń (dla przykładu `./debian/rules build` albo `make -f rules install`). Po nazwie celu możesz wymienić zależność, program lub plik, który od tej reguły zależy. W kolejnych liniach można wymienić dowolną liczbę komend, rozpoczynając je od znaku . Nowa reguła zaczyna się od deklaracji w pierwszej kolumnie. Puste linie i linie rozpoczynające się od znaku `#' (hash) są traktowane jako komentarz i ignorowane. Pewnie jesteś teraz nieco zagubiony, ale wszystko stanie się jasne w czasie przeglądania pliku `rules', który domyślnie zostanie stworzony przez program dh_make. Powinieneś też przeczytać o programie `make' (poprzez `info make'), aby uzyskać więcej informacji na jego temat. Ważne jest, aby pamiętać, że pliki `rules' stworzone przez dh_make są po prostu tylko propozycjami. Działają one z prostymi pakietami, ale w przypadku bardziej skomplikowanych nie obawiaj się ich modyfikować. Dodawaj to, co jest potrzebne i usuwaj to, co jest zbędne. Jedyną rzeczą, której nie możesz zmieniać to nazwy reguł, gdyż używają ich wszystkie narzędzia, zgodnie z wytycznymi zawartymi w Polityce Debiana. Poniżej pokazano (w przybliżeniu) domyślny plik debian/rules, który został dla nas wygenerowany przez program dh_make: 1 #!/usr/bin/make -f 2 # Sample debian/rules that uses debhelper. 3 # GNU copyright 1997 to 1999 by Joey Hess. 4 5 # Uncomment this to turn on verbose mode. 6 #export DH_VERBOSE=1 7 8 # This is the debhelper compatibility version to use. 9 export DH_COMPAT=3 10 11 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) 12 CFLAGS += -g 13 endif 14 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) 15 INSTALL_PROGRAM += -s 16 endif 17 18 build: build-stamp 19 build-stamp: 20 dh_testdir 21 22 # Add here commands to compile the package. 23 $(MAKE) 24 #/usr/bin/docbook-to-man debian/gentoo.sgml > gentoo.1 25 26 touch build-stamp 27 28 clean: 29 dh_testdir 30 dh_testroot 31 rm -f build-stamp 32 33 # Add here commands to clean up after the build process. 34 -$(MAKE) clean 35 36 dh_clean 37 38 install: build 39 dh_testdir 40 dh_testroot 41 dh_clean -k 42 dh_installdirs 43 44 # Add here commands to install the package into debian/gentoo. 45 $(MAKE) install DESTDIR=$(CURDIR)/debian/gentoo 46 47 # Build architecture-independent files here. 48 binary-indep: build install 49 # We have nothing to do by default. 50 51 # Build architecture-dependent files here. 52 binary-arch: build install 53 dh_testdir 54 dh_testroot 55 # dh_installdebconf 56 dh_installdocs 57 dh_installexamples 58 dh_installmenu 59 # dh_installlogrotate 60 # dh_installemacsen 61 # dh_installpam 62 # dh_installmime 63 # dh_installinit 64 dh_installcron 65 dh_installman 66 dh_installinfo 67 # dh_undocumented 68 dh_installchangelogs ChangeLog 69 dh_link 70 dh_strip 71 dh_compress 72 dh_fixperms 73 # dh_makeshlibs 74 dh_installdeb 75 # dh_perl 76 dh_shlibdeps 77 dh_gencontrol 78 dh_md5sums 79 dh_builddeb 80 81 binary: binary-indep binary-arch 82 .PHONY: build clean binary-indep binary-arch binary install (Numery linii zostały dodane przeze mnie) Z liniami takimi jak linia nr 1 prawdopodobnie spotkałeś się już w skryptach powłoki albo Perla. Mówi ona systemowi operacyjnemu, że plik ten ma być przetwarzany przez program `/usr/bin/make'. Znaczenie zmiennych DH_*, których użyto w liniach 6 i 9 powinno być zrozumiałe dzięki krótkiemu opisowi. Więcej informacji na temat zmiennej DH_COMPAT znajdziesz w sekcji "Debhelper compatibility levels" na stronie podręcznika programu debhelper(1). Linie 11-16 to szablon wspierający parametry DEB_BUILD_OPTIONS, które opisano w Polityce Debiana (sekcja 11.1 "Binaries"). Po prostu mówią one czy w binaria mają być wbudowane symbole służące do odpluskwiania (ang. debugging) i czy powinny one być usunięte przy instalacji. To jest szablon, wskazówka, którą powinineś/powinnaś wykonać. Musisz również sprawdzić w jaki sposób zewnętrzny system obsługuje włączanie symboli odpluskwiających i usuwanie ich po instalacji i zaimplementować to samemu. Zwykle możesz nakazać kompilatorowi gcc użycie opcji "-g" przy pomocy zmiennej CFLAGS. Jeśli tak jest w przypadku Twojego pakietu, przekaż wartość tej zmiennej _dodanie_ łańcucha `CFLAGS="$(CFLAGS)"' do wywołania $(MAKE) w regule `build' (zobacz poniżej). Jeśli zaś Twój pakiet używa skryptu konfiguracyjnego autoconfa, to możesz zmodyfikować konfigurację przez _poprzedzenie_ powyższym łańcuchem wywołania skryptu ./configure w regule `build'. Jeśli chodzi o pozbywanie się symboli odpluskwiających, to programy są na ogół tak skonfigurowane, że instalują się z nimi i często nie mają opcji umożliwiającej zmianę tego stanu. Na szczęście masz program dh_strip(1), który wykryje, gdy ustawiona jest opcja DEB_BUILD_OPTIONS=nostrip i bez rozgłosu zakończy swe działanie. Linie 18-26 opisują regułę `build' (i jej dziecko `build-stamp'), która uruchamia program make na oryginalnym pliku Makefile aplikacji, aby skompilować program. Na temat wykomentowanego przykładu pokazującego w jaki sposób przekonwertować dokument w formacie DocBook na stronę podręcznika systemowego opowiemy dalej, w rozdziale Rozdział 5.8, `Pliki `manpage.1.ex', `manpage.sgml.ex''. Reguła `clean' zawarta pomiędzy liniami 28-36 czyści wszystkie niepotrzebne pliki binarne i automatycznie wygenerowane rzeczy, które zostały po zbudowaniu pakietu. Reguła ta musi działać przez cały czas (nawet, gdy drzewo ze źródłami _jest_ wyczyszczone!), zatem proszę używać opcji wymuszającej (na przykład dla komeny rm jest nią opcja `-f') lub ignorującej zwracane wartości (błędy) dzięki zastosowaniu opcji `-' przed nazwą komendy. Reguła `install', która odpowiada za proces instalacji, rozpoczyna się w linii nr 38. Uruchamia ona po prostu regułę `install' z pliku Makefile programu i instaluje go w katalogu `$(CURDIR)/debian/gentoo'. Oto dlaczego określiliśmy zmienną $(DESTDIR) jako katalog bazowy do instalacji w pliku Makefile programu gentoo. Jak tłumaczy komentarz, reguła `binary-indep', która znajduje się w linii nr 48, jest używana do budowania pakietów niezależnych od architektury procesora. Jeśli nie mamy takiego pakietu, to żadna akcja nie zostanie wykonana. Następną regułą jest `binary-arch' znajdująca się pomiędzy liniami 52-79. Uruchamia ona kilka małych programów narzędziowych z pakietu debhelper, które wykonują różne operacje z plikami Twojego pakietu, aby uczynić go zgodnym z Polityką Debiana. Gdy określiłeś architekturę Twojego pakietu jako `Architecture: all', to będziesz musiał umieścić w tej regule wszystkie komendy do budowania pakietu i pozostawić pustą następną regułę (`binary-arch'). Nazwy programów wchodzących w skład pakietu debhelper rozpoczynają się od dh_. Reszta jest opisem tego, co dane narzędzie robi. Mimo, że dość dobrze same się one objaśniają, to poniżej zamieszczono dodatkowe wytłumaczenia: * dh_testdir(1) sprawdza czy jesteś we właściwym katalogu (tzn. na samej górze katalogu ze źródłami), * dh_testroot(1) sprawdza czy masz uprawnienia administratora systemu, których wymagają cele `binary-arch', `binary-indep' i `clean', * dh_installman(1) kopiuje strony podręcznika systemowego we właściwe miejsce w katalogu przeznaczenia. Musisz tylko powiedzieć, gdzie one się znajdują, względem głównego katalagu ze źródłami, * dh_strip(1) usuwa z plików wykonywalnych i bibliotek nagłówki służące do odpluskwiania, aby uczynić je mniejszymi, * dh_compress(1) pakuje programem gzip strony podręcznika i dokumentację większą niż 4 kB, * dh_installdeb(1) kopiuje pliki związane z pakietem (na przykład skrypty opiekuna) do katalogu `debian/gentoo/DEBIAN', * dh_shlibdeps(1) wylicza zależności bibliotek i plików wykonywalnych od bibliotek współdzielonych, * dh_gencontrol(1) instaluje "ulepszoną" wersję pliku `control' w katalogu `debian/gentoo/DEBIAN', * dh_md5sums(1) generuje sumy kontrolne MD5 dla każdego pliku zawartego w pakiecie. Dokładne informacje na temat działania każdego skryptu dh_* i ich parametrów wywołania znajdziesz na odpowiedniej stronie podręcznika. Oprócz wymienionych powyżej, istnieją również inne użyteczne skrypty dh_*, które nie zostały tu wspomniane. Jeśli potrzebujesz ich, to poczytaj dokumentację do pakietu debhelper. W sekcji `binary-arch' powinieneś naprawdę wykomentować linie z tymi wszystkimi skryptami dh_*, których nie chcesz wywoływać. Dla pakietu gentoo wykomentowałem wywołanie skryptów examples, cron, init, man i info, gdyż gentoo ich po prostu nie potrzebuje. W linii nr 68 zamieniłem `ChangeLog' na `FIXES', ponieważ jest to rzeczywista nazwa zewnętrznego pliku z dziennikiem zmian. Dwie ostatnie linie (i pozostałe nie wyjaśnione tutaj) są mniej lub bardziej niezbędne. Na ich temat możesz poczytać na stronie podręcznika do programu make oraz w Polityce Debiana. W tym momencie nie musisz o nich nic wiedzieć. ------------------------------------------------------------------------------- 5. Inne pliki z katalogu debian/ -------------------------------- Jak zobaczysz, w katalogu debian/ znajdują się jeszcze inne różne pliki. Większość z nich kończy się przyrostkiem `.ex', oznaczającym, że są to przykłady. Przyjrzyj im się wszystkim. Jeśli chcesz lub potrzebujesz użyć którejś ich funkcjonalności, to: * zajrzyj do odpowiedniej dokumentacji (wskazówka: podręcznik Polityki Debiana, * jeśli to konieczne, zmodyfikuj zawartość plików według własnych potrzeb, * usuń z ich nazwy przyrostek `.ex', jeśli taki posiadają, * usuń z ich nazwy przedrostek `ex.', jeśli taki posiadają, * zmodyfikuj plik `rules', gdy zachodzi taka konieczność. Niektóre z tych plików, najczęściej używane, są wyjaśnione w poniższych sekcjach. 5.1. Plik `README.Debian' ------------------------- W tym pliku powinny być udokumentowane dodatkowe szczegóły lub rozbieżności pomiędzy oryginalnym pakietem i Twoją "zdebianizowaną" wersją. Program dh_make tworzy domyślny plik README.Debian, który jest podobny do tego poniżej: gentoo for Debian ----------------- -- Josip Rodin , Wed, 11 Nov 1998 21:02:14 +0100 Ponieważ nie musimy niczego umieszczać w tym pliku, to możemy go skasować. 5.2. Plik `conffiles.ex' ------------------------ Jedną z najbardziej irytujących rzeczy związanych z oprogramowaniem jest to, że po poświęceniu dużej ilości czasu i wysiłku na dostosowaniu programu, jego aktualizacja wszystko "zadeptuje". Debian rozwiązał ten problem przez "znakowanie" plików konfiguracyjnych. Zatem, jeśli uaktualniasz program do nowszej wersji, to zostaniesz zapytany o to czy chcesz zachować swoją starą konfigurację, czy nie. Aby to uzyskać, musisz wprowadzić pełną ścieżkę do każdego pliku konfiguracyjnego (każda ścieżka w osobnej linii) do pliku nazwanego `conffiles'. Zwykle pliki te są umieszczone w katalogu /etc. Program gentoo ma jeden taki plik, /etc/gentoorc, zatem podamy ścieżkę do niego w pliku `conffiles'. Jeśli Twój program używa plików konfiguracyjnych, ale sam zmienia ich zawartość, to najlepiej będzie nie umieszczać ich w pliku `conffiles', ponieważ program dpkg będzie za każdym razem prosił użytkowników o weryfikację zmian. Jeśli program, który pakujesz, wymaga do działania od każdego użytkownika modyfikacji pliku konfiguracyjnego, to również powinieneś zastanowić się nad rezygnacją z umieszczania go w pliku `conffiles'. Przykładowe pliki konfiguracyjne możesz znaleźć w skryptach opiekuna pakietu. Więcej szczegółów na ich temat zamieszczono w sekcji Rozdział 5.12, `Pliki `postinst.ex', `preinst.ex', `postrm.ex', `prerm.ex''. Jeśli Twój program nie posiada plików konfiguracyjnych, to możesz bez obaw wykasować plik `conffiles' z katalogu debian/. 5.3. Plik `cron.d.ex' --------------------- Jeśli Twój pakiet do prawidłowego działania wymaga regularnie wykonywanych zadań, to możesz do tego celu wykorzystać właśnie plik `cron.d'. Zwróć uwagę, iż to nie obejmuje zagadnień związanych z "obracaniem" plików dziennika. Więcej informacji na ten temat znajdziesz na stronach podręcznika dh_installlogrotate(1) i logrotate(8). Jeśli nie potrzebujesz tego pliku, to usuń go. 5.4. Plik `dirs' ---------------- Plik ten określa katalogi, które są potrzebne, ale których normalna procedura instalacyjna (make install) nie tworzy. Domyślnie, plik ten wygląda następująco: usr/bin usr/sbin Zwróć uwagę, iż przed nazwami katalogów nie występują znaki ukośników (`/'). Normalnie zmienilibyśmy ją w następujący sposób: usr/bin usr/man/man1 ale ponieważ katalogi te są tworzone przez plik Makefile, to nie potrzebujemy pliku `dirs' i możemy go usunąć. 5.5. Plik `docs' ---------------- Ten plik określa nazwy plików z dokumentacją, którą program dh_installdocs zainstaluje dla nas w tymczasowym katalogu. Domyślnie, obejmuje to także istniejące już w katalogu głównym ze źródłami programu takie pliki, jak "BUGS", "README*", "TODO", itd. Dla programu gentoo dołączyłem również inne pliki: BUGS CONFIG-CHANGES CREDITS ONEWS README README.gtkrc TODO Zamiast podawać listę plików możemy również użyć ich nazw jako argumentów wejściowych dla programu `dh_installdocs' wywoływanego w pliku `rules': dh_installdocs BUGS CONFIG-CHANGES CREDITS ONEWS README \ README.gtkrc TODO Może się tak zdarzyć, że będziesz mieć żadnego z tych plików w źródłach Twojego pakietu. W takim przypadku możesz bezpiecznie usunąć ten plik. Nie usuwaj jedynie wywołania programu `dh_installdocs' z pliku `rules', ponieważ jest on używany również do instalacji pliku `copyright' i kilku innych rzeczy. 5.6. Plik `emacsen-*.ex' ------------------------ Jeśli Twój pakiet zawiera pliki Emacsa, które mogą być skompilowane do kodu bajtowego w czasie instalacji, to możesz użyć tych plików właśnie w tym celu. Pliki te są instalowane w katalogu tymczasowym przez program dh_installemacsen(1), zatem jeśli chcesz go wywołać, to nie zapomnij odkomentować odpowiedniej linii w pliku `rules'. Jeśli zaś nie potrzebujesz tych plików, to możesz je usunąć. 5.7. Plik `init.d.ex' --------------------- Jeśli Twój pakiet jest demonem, który musi być uruchamiany w czasie startu systemu, to znaczy, że nie posłuchałeś moich zaleceń we wstępie do tego podręcznika, nieprawdaż? :-) Plik ten jest prostym szablonem skryptu umieszczanego w katalogu `/etc/init.d/', zatem będziesz musiał nieźle go przerobić. Zostanie on zainstalowany w katalogu tymczasowym przez program dh_installinit(1). Jeśli nie potrzebujesz tego pliku, to usuń go. 5.8. Pliki `manpage.1.ex', `manpage.sgml.ex' -------------------------------------------- Twój program/programy powinien/powinny mieć stronę podręcznika systemowego. Jeśli jeszcze jej nie ma, to możesz użyć tych plikó jako szablonów. Strony podręcznika są zwykle napisane w formacie nroff(1). W formacie tym napisano właśnie przykładowy plik `manpage.1.ex'. Zobacz stronę podręcznika programu man(7), aby dowiedzieć się więcej na temat tworzenia stron podręcznika. Jeśli zamiast formatu nroff wolisz pisać dokumenty w formacie SGML, to możesz wykorzystać szablon `manpage.sgml.ex'. Będziesz też musiał: * zainstalować pakiet `docbook-to-man', * dopisać `docbook-to-man' do linii `Build-Depends' w pliku `control', * usunąć znak komentarza przed wywołaniem programu docbook-to-man w regule `build' w pliku `rules'. Pamiętaj o zmianie nazwy pliku na coś takiego jak `gentoo.sgml'! Nazwa pliku ze stroną podręcznika systemowego powinna zawierać nazwę programu, który opisuje, zatem zmień ją z "manpage" na "gentoo". Nazwa tego pliku zawiera także przyrostek ".1", który mówi, że jest to strona komendy użytkownika. Upewnij się, do której sekcji powinna należeć strona Twojego pakietu. Poniżej zamieszczono listę wyjaśniającą przeznaczenie każdej sekcji: Sekcja | Opis | Uwagi 1 Polecenia użytkownika Wykonywalne komendy lub skrypty. 2 Wywołania systemowe Funkcje dostarczane przez jądro systemu. 3 Wywołania biblioteczne Funkcje z bibliotek systemowych. 4 Pliki specjalne Zwykle umieszczone w katalogu /dev. 5 Formaty plików Na przykład format pliku /etc/passwd. 6 Gry Lub inne rozrywkowe programy. 7 Pakiety z makrami Takie jak makra programu man. 8 Administracja systemem Programy zwykle uruchamiane tylko przez administratora systemu. 9 Procedury jądra Niestandardowe wywołania i procedury wewnętrzne. Zatem strona programu gentoo powinna się nazywać `gentoo.1'. Dla programów przeznaczonych dla systemu X11 możesz dodać "x" do numeru sekcji, na przykład `gentoo.1x'. Ponieważ w oryginalnych źródłach nie było strony podręcznika `gentoo.1', to napisałem ją sam, używając informacji znalezionych w przykładach i dokumentacji dołączonej do źródeł. 5.9. Plik `menu.ex' ------------------- Użytkownicy systemu X Window zwykle posługują się menadżerami okien, umożliwiającymi uruchamianie programów poprzez rozwijalne menu, które można dostosowywać do własnych potrzeb. Jeśli zainstalowali oni pakiet `menu', to zostanie dla nich stworzony zestaw menu służący do uruchamiania programów w systemie. Poniżej pokazano plik `menu.ex', domyślnie utworzony przez program dh_make: ?package(gentoo):needs=X11|text|vc|wm section=Apps/see-menu-manual\ title="gentoo" command="/usr/bin/gentoo" Pierwszym polem po znaku dwukropka jest pole "needs", które określa jakiego rodzaju interfejsu wymaga program. Zmień je na jedną z wymienionych możliwości, na przykład "text" lub "X11". Następnym polem jest "section", które mówi w jakim menu i podmenu powinien znaleźć się wpis z programem gentoo. Aktualną listę sekcji można znaleźć na stronie `/usr/share/doc/debian-policy/menu-policy.html/ch2.html#s2.1' Trzecie pole "title" to nazwa programu. Jeśli chcesz, to możesz rozpocząć je od wielkiej litery. Powinno one być krótkie. Wreszcie pole "command" to nazwa komendy, która uruchamia program. Po zmianach wpis do menu wygląda następująco: ?package(gentoo): needs=X11 section=Apps/Tools title="Gentoo" command="gentoo" Możesz również dodać inne pola, na przykład "longtitle", "icon", "hints", itd. Więcej informacji możesz znaleźć na stronach podręcznika menufile(5), update-menus(1) i w katalogu /usr/share/doc/debian-policy/menu-policy.html/. 5.10. Plik `watch.ex' --------------------- Możesz użyć tego pliku jako dodatek do programów uscan(1) i uupdate(1) zawartych w pakiecie `devscripts', aby obserwować stronę, z której pobrałeś oryginalne źródła. Poniżej pokazano to, co umieściłem w tym pliku: # watch control file for uscan # Site Directory Pattern Version Script ftp.obsession.se /gentoo gentoo-(.*)\.tar\.gz debian uupdate Wskazówka: połącz się z Internetem i próbuj uruchomić program "uscan" w katalogu, w którym stworzyłeś plik `watch'. Przeczytaj również strony podręczników! :) 5.11. Plik `ex.package.doc-base' -------------------------------- Jeśli Twój pakiet ma dokumentację w postaci innej niż strony podręcznika i dokumentacja przeglądana za pomocą programu "info", to powinieneś użyć pliku ``doc-base'', aby ją zarejestrować. Użytkownik będzie mógł ją znaleźć, na przykład za pomocą programu dhelp(1), dwww(1) lub doccentral(1). Na ogół obejmuje to pliki HTML, PS i PDF umieszczone w katalogu `/usr/share/doc/nazwa_pakietu/'. Plik `gentoo.doc-base' dla programu gentoo wygląda następująco: Document: gentoo Title: Gentoo Manual Author: Emil Brink Abstract: This manual describes what Gentoo is, and how it can be used. Section: Apps/Tools Format: HTML Index: /usr/share/doc/gentoo/html/index.html Files: /usr/share/doc/gentoo/html/*.html Informacje na temat formatu tego pliku znajdziesz na stronie podręcznika install-docs(8) oraz w podręczniku `doc-base' (katalog `/usr/share/doc/doc-base/doc-base.html/'). 5.12. Pliki `postinst.ex', `preinst.ex', `postrm.ex', `prerm.ex' ---------------------------------------------------------------- Pliki te są nazywane skryptami opiekuna. Umieszczone są one w obszarze kontrolnym pakietu i uruchamiane przez program `dpkg', gdy Twój pakiet jest instalowany, uaktualniany do nowszej wersji lub usuwany. Na razie powinieneś/powinnaś unikać ręcznych modyfikacji tych skryptów, ponieważ często są one skomplikowane. Więcej informacji znajdziesz w podręczniku Polityki Debiana, w rozdziale 6. Zerknij także na przykładowe pliki dostarczone przez program dh_make. ------------------------------------------------------------------------------- 6. Budowanie pakietu -------------------- Teraz już powinniśmy być gotowi do zbudowania pakietu. 6.1. Całkowita przebudowa ------------------------- Wejdź do katalogu głównego programu i wydaj w nim komendę: dpkg-buildpackage -rfakeroot Wykona ona wszystko za Ciebie, tzn.: * wyczyści drzewo ze źródłami programu (debian/rules clean), używając programu `fakeroot', * zbuduje pakiet źródłowy (dpkg-source -b), * zbuduje program (debian/rules build), * zbuduje pakiet binarny (debian/rules binary), używając programu `fakeroot', * podpisze źródłowy plik `.dsc', używając programu `gnupg' * stworzy i podpisze umieszczany w archiwum Debiana plik `.changes', używając programów `dpkg-genchanges' i `gnupg'. Będziesz musiał tylko dwukrotnie wprowadzić hasło do Twojego prywatnego klucza GPG. Po jej zakończeniu zobaczysz następujące pliki w katalogu nadrzędnym (`~/debian/'): * _gentoo_0.9.12.orig.tar.gz_ To archiwum z oryginalnym kodem źródłowym programu. Jego nazwa została zmieniona, aby zachować standard Debiana. Zwróć uwagę, iż plik ten został stworzony przy użyciu opcji `-f' przez program `dh_make', gdy na wstępie go uruchomiliśmy. * _gentoo_0.9.12-1.dsc_ To streszczenie zawartości kodu źródłowego. Plik ten jest generowany na podstawie pliku `control' i używany w czasie rozpakowywania źródła przez program dpkg-source(1). Jest on podpisany cyfrowo przez PGP, aby inni ludzie mogli być pewni, że jest naprawdę Twój. * _gentoo_0.9.12-1.diff.gz_ Ten skompresowany plik zawiera wszystkie zmiany, których dokonałeś w oryginalnym kodzie źródłowym. Zmiany te są zapisane w formacie "unified diff". Plik jest utworzony i używany przez program dpkg-source(1). Ostrzeżenie: jeśli nie nazwałeś oryginalnego archiwum ze źródłami programu nazwa_programu_wersja.orig.tar.gz, to program `dpkg-source' nie wygeneruje poprawnego pliku .diff.gz! Gdyby ktoś jeszcze chciał ponownie utworzyć Twój pakiet zaczynając procedurę od początku, to może łatwo to zrobić używając tych trzech powyższych plików. Procedura postępowania w takich przypadkach jest wręcz banalna: po prostu należy gdzieś skopiować te trzy pliki i wydać komendę `dpkg-source -x gentoo_0.9.12-1.dsc'. * _gentoo_0.9.12-1_i386.deb_ To kompletny pakiet binarny. Możesz użyć programu `dpkg', aby zainstalować go lub usunąć w taki sam sposób, jak każdy inny pakiet. * _gentoo_0.9.12-1_i386.changes_ Plik ten opisuje wszystkie zmiany dokonane w aktualnej poprawce pakietu. Używają go programy utrzymujące archiwa FTP Debiana do zainstalowania w nich pakietów binarnych i źródłowych. Jest on częściowo generowany z plików `changelog' i .dsc. Jest on podpisany cyfrowo przez PGP, aby inni ludzie mogli być pewni, że jest naprawdę Twój. W czasie, gdy będziesz się zajmował pakietem, zmieni się pewnie jego działanie i dodane zostaną nowe funkcjonalności. Ludzie pobierający Twój pakiet mogą w tym pliku szybko zobaczyć, co się zmieniło. Programy zarządzające archiwum Debiana wyślą również zawartość tego pliku na listę dyskusyjną debian-devel-changes. Długie łańcuchy liczb w plikach .dsc i .changes to sumy kontrolne MD5 wspomnianych plików. Osoby pobierające Twoje pliki mogą sprawdzić je używając programu md5sum(1) i jeśli sumy nie będą się zgadzać, to będą wiedzieć, że plik jest uszkodzony lub został przez kogoś celowo zmieniony. 6.2. Szybka przebudowa ---------------------- Gdy masz duży pakiet, to możesz nie chcieć budować go od nowa za każdym razem, gdy zmienisz jakiś szczegół w pliku `debian/rules'. Dla celów testowych możesz stworzyć pakiet .deb, który nie będzie odbudowywany z zewnętrznych źródeł: fakeroot debian/rules binary Gdy już zakończyłeś szlifowanie Twojego pakietu, pamiętaj o przebudowaniu go zgodnie z powyższą procedurą. Może Ci się nie udać umieścić go w archiwum Debiana, gdy próbujesz zamieścić tam pliki .deb zbudowane w ten sposób. ------------------------------------------------------------------------------- 7. Sprawdzanie czy w pakiecie nie ma błędów ------------------------------------------- Uruchom program lintian(1), podając jako argument swój plik .changes. Program ten sprawdza czy w pakiecie nie występują najczęstsze błędy. Uruchom go w następujący sposób: lintian -i gentoo_0.9.12-1_i386.changes Oczywiście zastąp nazwę pliku .changes nazwą pliku wygenerowanego dla Twojego pakietu. Jeśli pojawią się informacje o błędach (linie rozpoczynające się od "E:"), to przeczytaj ich objaśnienie (linie rozpoczynające się od "N:"), popraw je i ponownie zbuduj pakiet w taki sposób, jak to zostało opisane w sekcji Rozdział 6.1, `Całkowita przebudowa'. Linie, które zaczynają się od "W:" to tylko ostrzeżenia. Oczywiście powinieneś albo coś poprawić, żeby już nie występowały, albo upewnić się, że nie są ważne (i w takim przypadku wymusić na Lintianie ich ignorowanie; wiecej szczegółów znajdziesz w dokumentacji). Zwróć uwagę, iż możesz w jednym kroku zbudować pakiet za pomocą programu `dpkg-buildpackage' i uruchomić program `lintian' korzystając z narzędzia zwanego debuild(1). Zajrzyj do pakietu używając takiego menadżera plików jak mc(1) lub rozpakuj go w jakimś tymczasowym miejscu przy pomocy programu dpkg-deb(1). Sprawdź, czy zarówno pakiet binarny jak i źródłowy nie zawiera niepotrzebnych plików. Często coś nie zostaje wyczyszczone tak, jak powinno; zastosuj wtedy Twój plik `rules', aby to poprawić. Porada: komenda `zgrep ^+++ ../gentoo_0.9.12-1.diff.gz` poda Ci listę Twoich zmian/dodatków w plikach źródłowych, a polecenie `dpkg-deb -c gentoo_0.9.12-1_i386.deb` - listę plików w pakiecie binarnym. Zainstaluj pakiet, żeby samemu go przetestować, na przykład wydając komendę debi(1) jako administrator systemu. Spróbuj go także zainstalować i uruchomić na maszynach innych niż Twoja i obserwuj uważnie czy w czasie instalacji i uruchamiania programu nie wystąpiły jakieś błędy lub ostrzeżenia. ------------------------------------------------------------------------------- 8. Umieszczanie pakietu w archiwum ---------------------------------- Gdy już gruntownie przetestowałeś/przetestowałaś swój nowy pakiet, jesteś gotowy/gotowa aby rozpocząć proces przyjęcia do projektu jako nowego opiekuna pakietów. Jest on dokładnie opisany na stronie http://www.debian.org/devel/join/newmaint. Gdy już zostałeś oficjalnym rozwijającym Debiana, to musisz umieścić swój pakiet w archiwum Debiana. Możesz zrobić to ręcznie, ale łatwiej jest użyć specjalnie do tego celu stworzonych narzędzi, które zautomatyzują cały proces. Należą do niech takie programy, jak dupload(1) i dput(1). Opiszemy tutaj w jaki sposób posługiwać się programem `dupload'. Pierwsza rzeczą, którą powinniśmy zrobić jest ustawienie jego pliku konfiguracyjnego. Możesz wyedytować zarówno przeznaczony dla całego systemu plik `/etc/dupload.conf', jak i swój własny plik `~/.dupload.conf', który nadpisuje te rzeczy, które chcesz zmienić. Umieść w nim coś takiego jak poniżej: package config; $default_host = "ftp-master"; $cfg{"ftp-master"}{"login"} = "twoja_nazwa_użytkownika"; $cfg{"non-us"}{"login"} = "twoja_nazwa_użytkownika"; 1; Oczywiście powinieneś/powinnaś zmienić moje osobiste ustawienia na swoje. Przeczytaj też stronę podręcznika dupload.conf(5), aby zrozumieć co oznacza każda z użytych opcji. Uwagi wymaga zmienna $default_host -- określa ona, która z kolejek służących do umieszczania pakietów jest używana domyślnie. Główną kolejka jest "ftp-master", ale możliwe jest, że będziesz chciał użyć innej, na przykład szybszej. Więcej informacji na temat tych kolejek znajdziesz w dokumencie Developers' Reference, w sekcji "Uploading a package", która znajduje się na stronie `/usr/share/doc/developers-reference/developers-reference.html/ch-upload.en.html#s-uploading'. Następnie połącz się z Internetem i wydaj komendę: dupload gentoo_0.9.12-1_i386.changes Program `dupload' sprawdzi czy zgadzają się sumy kontrolne MD5 plików z sumami zapisanymi w pliku .changes. Jeśli sumy kontrolne pasują do siebie, to pakiet może być umieszczony w archiwum. Jeśli sumy się nie zgadzają, to `dupload' ostrzeże Cię o tym fakcie, żebyś ponownie zbudował/zbudowała pakiet zgodnie z procedurą opisaną w sekcji Rozdział 6.1, `Całkowita przebudowa'. Jeśli umieszczasz swój pakiet w kolejce "ftp-master", to program `dupload' poprosi Cię o Twoje hasło na maszynach Debiana i dopiero wtedy umieści Twój pakiet. ------------------------------------------------------------------------------- 9. Aktualizacja pakietu ----------------------- 9.1. Nowa poprawka Debiana -------------------------- Powiedzmy, że został zgłoszony raport nr #54321 o błędzie w Twoim pakiecie i opisuje problem, który możesz rozwiązać. Aby stworzyć nową poprawkę pakietu Debiana musisz wykonać następujące czynności: * Oczywiście najpierw popraw problem w źródłach pakietu. * Dodaj nową poprawkę na początku pliku `changelog', na przykład za pomocą komendy `dch -i` lub dokładniej `dch -v -` i wtedy za pomocą ulubionego edytora tekstu wstaw komentarze. Porada: w jaki sposób najłatwiej pobrać datę w wymaganym formacie? Użyj komendy `822-date` lub `date -R`. Dołącz krótki opis błędu i jego rozwiązania do pliku `changelog', oraz napis: "Closes: #54321". W ten sposób raport o błędzie zostanie automatycznie zamknięty przez oprogramowanie obsługujące archiwum w momencie, gdy pakiet zostanie przez nie zaakceptowany. * Powtórz to, co zrobiłeś w sekcjach Rozdział 6.1, `Całkowita przebudowa', Część 7, `Sprawdzanie czy w pakiecie nie ma błędów' i Część 8, `Umieszczanie pakietu w archiwum'. Jedyną różnicą teraz będzie nie włączenie oryginalnego archiwum ze źródłem programu, gdyż znajduje się ono już w archiwum Debiana i nie zostało zmienione. 9.2. Nowe wydanie programu -------------------------- Rozważmy teraz trochę inną, bardziej skomplikowaną sytuację - została wydana nowa, zewnętrzna wersja programu i oczywiście chcemy ją zapakować. Musimy wykonać następujące czynności: * Pobierz archiwum z nowymi źródłami (na przykład nazwane `gentoo-0.9.13.tar.gz') i umieść je w katalogu nadrzędnym do katalogu ze starym drzewem źródeł (dla przykładu ~/debian/). * Wejdź do katalogu ze starymi źródłami i wydaj komendę: uupdate -u gentoo-0.9.13.tar.gz Oczywiście musisz zastąpić nazwę pliku nazwą archiwum ze źródłami Twojego programu. Program uupdate(1) odpowiednio zmieni nazwę tego archiwum, spróbuje nałożyć wszystkie zmiany z Twojego poprzedniego pliku .diff.gz. i uaktualni nowy plik debian/changelog. * Zmień katalog na `../gentoo-0.9.13', czyli drzewo z nowym źródłem pakietu i powtórz to, co zrobiłeś w sekcjach Rozdział 6.1, `Całkowita przebudowa', Część 7, `Sprawdzanie czy w pakiecie nie ma błędów' i Część 8, `Umieszczanie pakietu w archiwum'. Zauważ, że jeśli ustawiłeś plik `debian/watch' tak, jak to opisano w sekcji Rozdział 5.10, `Plik `watch.ex'', to możesz uruchomić program uscan(1), aby automagicznie odszukiwać poprawione źródła, pobierać je i uruchamiać program `uupdate'. 9.3. Weryfikowanie uaktualnienia pakietu do nowszej wersji ---------------------------------------------------------- Gdy będziesz budować nową wersję pakietu, powinieneś wykonać następującą procedurę, żeby upewnić się, że aktualizacja pakietu do nowej wersji przebiega bezbłędnie: * uaktualnij pakiet z poprzedniej wersji, * powróć ponownie do poprzedniej wersji i następnie usuń ją, * zainstaluj pakiet jako nowy pakiet, * odinstaluj go i następnie zainstaluj ponownie, * wyczyść (purge) pakiet. Miej świadomość, że jeśli Twój pakiet był poprzednio wydany w Debianie, to ludzie często będą go uaktualniać z wersji, która była w ostatnim wydaniu Debiana. Pamiętaj także, żeby przetestować uaktualnianie do nowszej wersji z tamtej wersji. ------------------------------------------------------------------------------- 10. Gdzie prosić o pomoc ------------------------ Zanim zdecydujesz się zadać pytanie w jakimś publicznym miejscu, proszę najpierw zajrzeć do odpowiedniego podręcznika. Dokumentacja do wszystkich programów wymienionych w tym dokumencie znajduje się w katalogach `/usr/share/doc/dpkg', `/usr/share/doc/debian', `/usr/share/doc/pakiet/*' oraz na stronach podręcznika man/info. Jeśli masz pytanie na temat pakowania, na które nie znalazłeś odpowiedzi w powyższej dokumentacji, to powinieneś je zadać na liście Mentorów Debiana, która dostępna jest pod adresem . Bardziej doświadczeni rozwijający Debiana z chęcią Ci pomogą, ale przed zadaniem pytania powinieneś co najmniej przeczytać wymienioną dokumentację! Więcej informacji na temat tej listy dyskusyjnej znajdziesz na stronie http://lists.debian.org/debian-mentors/. Gdy odbierzesz raport o błędzie (tak prawdziwy raport o błędzie!), to znak, że czas zaznajomić się z Systemem śledzenia błędów Debiana (http://www.debian.org/Bugs/) i przeczytać znajdującą się tam dokumentację, aby móc sprawnie radzić sobie z takimi raportami. Polecam głównie przeczytanie rozdziału "Handling Bugs" z dokumentu Developers' Reference. Rozdział ten jest dostępny na stronie `/usr/share/doc/developers-reference/developers-reference.html/ch-bug-handling.en.html' Jeśli wciąż masz pytania, to zapytaj na liście Rozwijających Debiana, która jest dostępna pod adresem . Więcej informacji na temat tej listy dyskusyjnej znajdziesz na stronie http://lists.debian.org/debian-devel/. Nawet, gdy wszystko działa dobrze, to czas, żeby zacząć się modlić. Dlaczego? Ponieważ już za kilka godzin (lub dni) użytkownicy z całego świata zaczną używać Twojego pakietu i jeśli popełniłeś jakiś krytyczny błąd, to zasypie Cię listami wielu rozgniewanych użytkowników Debiana... To oczywiście jest żart. :-) Zrelaksuj się i bądź gotowy na raporty o błędach, ponieważ jest dużo więcej pracy do zrobienia zanim Twój pakiet będzie w zgodzie z Polityką Debiana (powtarzam: przeczytaj _prawdziwą dokumentację_, aby dowiedzieć się więcej szczegółów). Powodzenia! ------------------------------------------------------------------------------- Podręcznik dla nowych opiekunów pakietów Debiana Josip Rodin polskie tłumaczenie: Paweł Tęcza korekta tłumaczenia: Marcin Owsiany wersja oryginału: 1.2, 6 kwietnia 2002. wersja tłumaczenia: 1.2.2, 17 marca 2004