Author: glen Date: Mon Jun 7 14:53:58 2010 GMT Module: PLD-doc Tag: HEAD ---- Log message: - utf8
---- Files affected: PLD-doc: devel-hints-pl.txt (1.65 -> 1.66) ---- Diffs: ================================================================ Index: PLD-doc/devel-hints-pl.txt diff -u PLD-doc/devel-hints-pl.txt:1.65 PLD-doc/devel-hints-pl.txt:1.66 --- PLD-doc/devel-hints-pl.txt:1.65 Mon Jun 7 11:05:01 2010 +++ PLD-doc/devel-hints-pl.txt Mon Jun 7 16:53:53 2010 @@ -1,143 +1,143 @@ UWAGA: - oficjalna wersja tego dokumentu znajduje si� wpliku devel-hints-en.txt. - Polskie t�umaczenie mo�e by� niepe�ne/nieaktualne (poza fragmentem - dotycz�cym zasad polszczyzny w opisach pakiet�w). W przypadku w�tpliwo�ci, - zajrzyj do odpowiedniej sekcji devel-hints-pl.txt. Je�eli zauwa�ysz - rozbie�no�� mi�dzy wersj� angielsk� i polsk�, popraw, albo przynajmniej - wyra�nie oznacz odpowiednie miejsce. + oficjalna wersja tego dokumentu znajduje się wpliku devel-hints-en.txt. + Polskie tłumaczenie może być niepełne/nieaktualne (poza fragmentem + dotyczącym zasad polszczyzny w opisach pakietów). W przypadku wątpliwości, + zajrzyj do odpowiedniej sekcji devel-hints-pl.txt. Jeżeli zauważysz + rozbieżność między wersją angielską i polską, popraw, albo przynajmniej + wyraźnie oznacz odpowiednie miejsce. TODO: - przenie�� struktur� devel-hints-en.txt. Docelowo poszczeg�lne fragmenty obu - dokument�w powinny mie� takie same numery sekcji. U�atwi to r�wnoleg�e - utrzymywanie dw�ch wersji j�zykowych dokumentu. + przenieść strukturę devel-hints-en.txt. Docelowo poszczególne fragmenty obu + dokumentów powinny mieć takie same numery sekcji. Ułatwi to równoległe + utrzymywanie dwóch wersji językowych dokumentu. -Wskaz�wki dla deweloper�w PLD +Wskazówki dla deweloperów PLD -Nale�y pami�ta�, �e projekt PLD jest prac� zespo�ow�; podstawowymi listami -dyskusyjnymi dla developer�w s� [email protected] (w j�zyku -polskim) i [email protected] (w j�zyku angielskim). Listy te -s� przeznaczone mi�dzy innymi do omawiania dokonanych zmian w repozytorium +Należy pamiętać, że projekt PLD jest pracą zespołową; podstawowymi listami +dyskusyjnymi dla developerów są [email protected] (w języku +polskim) i [email protected] (w języku angielskim). Listy te +są przeznaczone między innymi do omawiania dokonanych zmian w repozytorium i dyskutowania zmian planowanych. -Dodaj�c speca nie bazuj�cego na template*.spec nale�y go potraktowa� -skryptem adapter.awk (wi�cej o u�ywaniu tego skryptu mo�na znale�� (po -angielsku) na http://www.pld-linux.org/ w sekcji dla deweloper�w). - -Spece bazuj�ce na template*.spec tak�e mo�na przepu�ci� przez adapter, -aby poprawi� formatowanie linii w preambu�ach i opisach. Uwaga: skrypt -ten nale�y uruchamia� przy ustawionej lokalizacji z kodowaniem UTF-8 -(np. pl_PL.UTF-8 lub en_GB.UTF-8), aby poprawnie rozpozna� d�ugo�� +Dodając speca nie bazującego na template*.spec należy go potraktować +skryptem adapter.awk (więcej o używaniu tego skryptu można znaleźć (po +angielsku) na http://www.pld-linux.org/ w sekcji dla deweloperów). + +Spece bazujące na template*.spec także można przepuścić przez adapter, +aby poprawić formatowanie linii w preambułach i opisach. Uwaga: skrypt +ten należy uruchamiać przy ustawionej lokalizacji z kodowaniem UTF-8 +(np. pl_PL.UTF-8 lub en_GB.UTF-8), aby poprawnie rozpoznał długość linii. -Pakiet musi si� budowa� z konta zwyk�ego u�ytkownika bez dodatkowych +Pakiet musi się budować z konta zwykłego użytkownika bez dodatkowych kombinacji. -Polskie opisy powinny by� w j�zyku polskim. -W szczeg�lno�ci dotyczy to ortografii, stosowania znak�w diakrytycznych -oraz apostrof�w i odmiany nazw w�asnych i skr�towc�w. W skr�cie: -- apostrof�w u�ywa si� tylko do oddzielenia ko�c�wki, je�eli przed ni� - jest samog�oska niema lub samog�oska niema z niemym "s" lub "x" +Polskie opisy powinny być w języku polskim. +W szczególności dotyczy to ortografii, stosowania znaków diakrytycznych +oraz apostrofów i odmiany nazw własnych i skrótowców. W skrócie: +- apostrofów używa się tylko do oddzielenia końcówki, jeżeli przed nią + jest samogłoska niema lub samogłoska niema z niemym "s" lub "x" (czyli np. Apache'a; ale NIE Blackbox'a czy IceWM'a) -- w przypadku skr�towc�w ko�c�wk� oddzielamy ��cznikiem (czyli np. +- w przypadku skrótowców końcówkę oddzielamy łącznikiem (czyli np. IceWM-a) -- "zwyk�e" nazwy oraz skr�towce o charakterze rzeczownika (typu - "Cepelia") odmieniamy bez ��cznika przed ko�c�wk� (czyli np. +- "zwykłe" nazwy oraz skrótowce o charakterze rzeczownika (typu + "Cepelia") odmieniamy bez łącznika przed końcówką (czyli np. AfterStepa, Sawfisha) - nazwy typu "Hortex", "Pewex" odmieniamy -ex, -eksu, -eksem, -ksie itd. (czyli np. Blackboksa, Postfiksa) -Pliki .spec (podobnie jak pliki .desktop) obecnie s� kodowane w UTF-8, wi�c -w tym kodowaniu musz� by� zlokalizowane opisy (w tym polskie, oznaczone -lokalizacj� pl_PL.UTF-8). Jedynie g��wne opisy (Summary:, %description bez --l) powinny by� utrzymywane w czystym ASCII (mo�na natomiast doda� opisy -z lokalizacj� en_GB.UTF-8 lub en_US.UTF-8 ze znakami spoza ASCII). - -Zawarto�� sekcji "description" nale�y formatowa� na 70 znak�w. - -Nazwy pakiet�w: -W przypadku niekt�rych klas pakiet�w stosujemy ujednolicone nazewnictwo. -W szczeg�lno�ci: -- dla modu��w Apache'a 2.x: apache-mod_<nazwa> -- dla modu��w Apache'a 1.3.x: apache1-mod_<nazwa> -- dla modu��w PAM: pam-pam_nazwa -- dla modu��w PEAR-a: php-pear-nazwa (gdzie nazwa zazwyczaj jest postaci +Pliki .spec (podobnie jak pliki .desktop) obecnie są kodowane w UTF-8, więc +w tym kodowaniu muszą być zlokalizowane opisy (w tym polskie, oznaczone +lokalizacją pl_PL.UTF-8). Jedynie główne opisy (Summary:, %description bez +-l) powinny być utrzymywane w czystym ASCII (można natomiast dodać opisy +z lokalizacją en_GB.UTF-8 lub en_US.UTF-8 ze znakami spoza ASCII). + +Zawartość sekcji "description" należy formatować na 70 znaków. + +Nazwy pakietów: +W przypadku niektórych klas pakietów stosujemy ujednolicone nazewnictwo. +W szczególności: +- dla modułów Apache'a 2.x: apache-mod_<nazwa> +- dla modułów Apache'a 1.3.x: apache1-mod_<nazwa> +- dla modułów PAM: pam-pam_nazwa +- dla modułów PEAR-a: php-pear-nazwa (gdzie nazwa zazwyczaj jest postaci Klasa[_Klasa[_Klasa...]] -- dla modu��w binarnych PECL, b�d�cych rozszerzeniami PHP: php-pecl-nazwa -- dla modu��w j�dra: kernel-typ-nazwa (typ jest taki sam, jak podkatalog - w drivers/ w kt�rym znalaz�by si� modu� - np. char, net itd.) -- dla nienatywnych bibliotek: <j�zyk>-<nazwa>, na przyk�ad: - * dla modu��w Perla: perl-nazwa (dla modu��w obiektowych zazwyczaj +- dla modułów binarnych PECL, będących rozszerzeniami PHP: php-pecl-nazwa +- dla modułów jądra: kernel-typ-nazwa (typ jest taki sam, jak podkatalog + w drivers/ w którym znalazłby się moduł - np. char, net itd.) +- dla nienatywnych bibliotek: <język>-<nazwa>, na przykład: + * dla modułów Perla: perl-nazwa (dla modułów obiektowych zazwyczaj nazwa jest postaci Klasa[-Klasa[-Klasa...]] - * dla modu��w Pythona: python-<nazwa> + * dla modułów Pythona: python-<nazwa> * dla bibliotek Javy: java-<nazwa> * dla bibliotek Rubyego: ruby-<nazwa> -Zauwa�, �e niekt�re pakiety mog� zawiera� bibliotek� i aplikacj� korzystaj�c� -z tej biblioteki. W takim przypadku powiniene� rozbi� pakiet na podpakiety: -<nazwa> i <j�zyk>-<nazwa>. Je�li aplikacja jest jedynie ma�ym przyk�adem -ilustruj�cym zastosowanie biblioteki, spec powinien si� nazywa� -<j�zyk>-<nazwa>.spec. W przeciwnym przypadku, to znaczy kiedy mamy do -czynienia z "prawdziw�" aplikacj�, natomiat biblioteka jest wykorzystywana -g��wnie przez t� aplikacj�, spec mo�e si� nazywa� <nazwa>.spec (wskaz�wka: -u�yj flagi -n aby utworzy� podpakiet bez prefiksu <nazwa>). Aby obejrze� -przyk�ad takiego pakietu zobacz ack.spec. - -Podzia� na podpakiety: -Pakiety zawieraj�ce biblioteki dzielone standardowo dzielimy na: -podstawowy (zawieraj�cy pliki m.in. lib*.so.*.*, podstawow� dokumentacj� - przydatn� dla u�ytkownika i wywo�anie /sbin/ldconfig w skryptach +Zauważ, że niektóre pakiety mogą zawierać bibliotekę i aplikację korzystającą +z tej biblioteki. W takim przypadku powinieneś rozbić pakiet na podpakiety: +<nazwa> i <język>-<nazwa>. Jeśli aplikacja jest jedynie małym przykładem +ilustrującym zastosowanie biblioteki, spec powinien się nazywać +<język>-<nazwa>.spec. W przeciwnym przypadku, to znaczy kiedy mamy do +czynienia z "prawdziwą" aplikacją, natomiat biblioteka jest wykorzystywana +głównie przez tę aplikację, spec może się nazywać <nazwa>.spec (wskazówka: +użyj flagi -n aby utworzyć podpakiet bez prefiksu <nazwa>). Aby obejrzeć +przykład takiego pakietu zobacz ack.spec. + +Podział na podpakiety: +Pakiety zawierające biblioteki dzielone standardowo dzielimy na: +podstawowy (zawierający pliki m.in. lib*.so.*.*, podstawową dokumentację + przydatną dla użytkownika i wywołanie /sbin/ldconfig w skryptach %post/%postun) -pakiet -devel (pliki nag��wkowe, dowi�zanie lib*.so, ewentualnie pliki - typu *.la, *.m4, *.pc, skrypty *-config oraz dokumentacj� dla - programist�w) -pakiet -static (zawieraj�cy tylko biblioteki statyczne (lib*.a) maj�ce - swoje odpowiedniki wsp��dzielone (czasem pod nieco inn� nazw� - - liczy si� ABI); biblioteki wyst�puj�ce tylko w wersji statycznej - powinny znale�� si� w pakiecie -devel) - -Uwaga: W niekt�rych aplikacjach (g��wnie z KDE) pliki *.la musz� znajdowa� -si� w pakiecie podstawowym i _s�_ konieczne do pracy aplikacji - wtedy -nale�y _koniecznie_ zaznaczy� komentarzem ten fakt w specu. - -Wersje pakiet�w: -Dla pe�nych wyda� pole Version zawiera wersj� pakietu. -Dla wersji rozwojowych lub testowych (snapshot�w z CVS, wszelkich alpha, -beta, gamma, pre, rc), aby unikn�� ci�g�ego podbijania Epoch, w polu +pakiet -devel (pliki nagłówkowe, dowiązanie lib*.so, ewentualnie pliki + typu *.la, *.m4, *.pc, skrypty *-config oraz dokumentację dla + programistów) +pakiet -static (zawierający tylko biblioteki statyczne (lib*.a) mające + swoje odpowiedniki współdzielone (czasem pod nieco inną nazwą - + liczy się ABI); biblioteki występujące tylko w wersji statycznej + powinny znaleźć się w pakiecie -devel) + +Uwaga: W niektórych aplikacjach (głównie z KDE) pliki *.la muszą znajdować +się w pakiecie podstawowym i _są_ konieczne do pracy aplikacji - wtedy +należy _koniecznie_ zaznaczyć komentarzem ten fakt w specu. + +Wersje pakietów: +Dla pełnych wydań pole Version zawiera wersję pakietu. +Dla wersji rozwojowych lub testowych (snapshotów z CVS, wszelkich alpha, +beta, gamma, pre, rc), aby uniknąć ciągłego podbijania Epoch, w polu Version wpisujemy tylko podstawowy (docelowy) numer wersji, natomiast -w Release umieszczamy ci�g 0.wersja-pre.rzeczywisty-release (np. dla wersji -rc2 i beta b�d� to 0.rc2.1, dla snapshot�w ci�g typu 0.20030303.1). -Przyk�adowy opis w specu (wersja rzeczywista: 2.0rc1) +w Release umieszczamy ciąg 0.wersja-pre.rzeczywisty-release (np. dla wersji +rc2 i beta będą to 0.rc2.1, dla snapshotów ciąg typu 0.20030303.1). +Przykładowy opis w specu (wersja rzeczywista: 2.0rc1) Version: 2.0 %define rcver rc1 Release: 0.%{rcver}.1 W takim przypadku po zmianach speca dla tej samej wersji oprogramowania -zwi�kszamy ostatni� liczb� w Release ("0" pozostaje bez zmian!). +zwiększamy ostatnią liczbę w Release ("0" pozostaje bez zmian!). -Grupy pakiet�w: -Pakiet musi posiada� zdefiniowane pole Group: zgodnie z packages/rpm.groups +Grupy pakietów: +Pakiet musi posiadać zdefiniowane pole Group: zgodnie z packages/rpm.groups Nie umieszczamy "BuildRequires: kernel-headers" w pakietach z samymi -programami user-space (sam pakiet glibc-devel wymaga w�a�ciwych -nag��wk�w j�dra). Taka zale�no�� powinna pojawia� si� tylko -w pakietach zawieraj�cych modu�y j�dra, i to warunkowo, czyli jako: +programami user-space (sam pakiet glibc-devel wymaga właściwych +nagłówków jądra). Taka zależność powinna pojawiać się tylko +w pakietach zawierających moduły jądra, i to warunkowo, czyli jako: %{?with_dist_kernel:BuildRequires: kernel-headers} -Podobnie nie umieszczamy zale�no�ci od j�dra w pakietach nie -zawieraj�cych modu��w; w pakietach z modu�ami umieszczamy j� warunkowo: +Podobnie nie umieszczamy zależności od jądra w pakietach nie +zawierających modułów; w pakietach z modułami umieszczamy ją warunkowo: %{?with_dist_kernel:%requires_releq_kernel_up} - (dla modu��w j�dra UP) + (dla modułów jądra UP) lub %{?with_dist_kernel:%requires_releq_kernel_smp} - (dla modu��w j�dra SMP) + (dla modułów jądra SMP) -Dodaj�c wywo�ania narz�dzi auto* i *ize nale�y pami�ta� o dopisywaniu -zale�no�ci: +Dodając wywołania narzędzi auto* i *ize należy pamiętać o dopisywaniu +zależności: autoconf,autoheader BuildRequires: autoconf automake,aclocal BuildRequires: automake @@ -147,27 +147,27 @@ intltoolize BuildRequires: intltool xml-i18n-toolize BuildRequires: intltool -Dobrze jest sprawdzi� wymagane wersje narz�dzi - opr�cz dokumentacji -cz�sto mo�na je znale�� w nast�puj�cych miejscach: +Dobrze jest sprawdzić wymagane wersje narzędzi - oprócz dokumentacji +często można je znaleźć w następujących miejscach: autoconf - w makrze AC_PREREQ(wersja) w configure.{ac,in} lub *.m4 automake - w AUTOMAKE_OPTIONS w Makefile.am lub w makrze AM_INIT_AUTOMAKE - w configure.{ac,in} (tylko w nowej sk�adni - w starej podawa�o - si� nazw� i wersj� pakietu) + w configure.{ac,in} (tylko w nowej składni - w starej podawało + się nazwę i wersję pakietu) gettext - w makrze AM_GNU_GETTEXT_VERSION w configure.{ac,in} libtool: - - je�li pakiet zawiera biblioteki dzielone i przynajmniej jedna - jest linkowana z inn� z tego samego pakietu - wymagana jest + - jeśli pakiet zawiera biblioteki dzielone i przynajmniej jedna + jest linkowana z inną z tego samego pakietu - wymagana jest wersja >= 0:1.4.2-9 - - je�li pakiet zawiera bibliotek� dzielon� w C++ (korzystaj�c� + - jeśli pakiet zawiera bibliotekę dzieloną w C++ (korzystającą z biblioteki standardowej libstdc++), wymagana jest wersja >= 2:1.4d - - je�li oba powy�sze warunki s� spe�nione, to wersja >= 2:1.4d-3 - - je�li w pliku configure.ac (nie configure.in) znajduje si� + - jeśli oba powyższe warunki są spełnione, to wersja >= 2:1.4d-3 + - jeśli w pliku configure.ac (nie configure.in) znajduje się makro AC_CONFIG_AUX_DIR, to wersja >= 1:1.4.3 (lub 2:1.4e w przypadku bibliotek w C++) -O ile to mo�liwe, programy te uruchamiamy u�ywaj�c makr (dla informacji -z prawej podane s� rozwini�cia tych makr): +O ile to możliwe, programy te uruchamiamy używając makr (dla informacji +z prawej podane są rozwinięcia tych makr): %{__autoconf} = autoconf %{__autoheader} = autoheader @@ -176,19 +176,19 @@ %{__libtoolize} = libtoolize --copy --force %{__intltoolize} = intltoolize --copy --force %{__gettextize} = gettextize --copy --force [--intl] - (+inne operacje zale�ne od u�ytej wersji gettexta) + (+inne operacje zależne od użytej wersji gettexta) %{__autopoint} = autopoint --force -Oczywi�cie w razie potrzeby mo�na podawa� za makrem dodatkowe parametry -do programu (z wyj�tkiem gettextize). -Zdarzaj� si� problemy z automake, je�li uruchamiane jest w podkatalogu -z opcj� --force (zawart� w makrze %{__automake}) - wtedy zamiast makra -nale�y u�y� samego: +Oczywiście w razie potrzeby można podawać za makrem dodatkowe parametry +do programu (z wyjątkiem gettextize). +Zdarzają się problemy z automake, jeśli uruchamiane jest w podkatalogu +z opcją --force (zawartą w makrze %{__automake}) - wtedy zamiast makra +należy użyć samego: automake -a -c --foreign -(opcja --foreign w wielu przypadkach jest istotna, poniewa� bez niej -automake nadpisuje pliki typu COPYING czy INSTALL w�asnymi wersjami) +(opcja --foreign w wielu przypadkach jest istotna, ponieważ bez niej +automake nadpisuje pliki typu COPYING czy INSTALL własnymi wersjami) -Powy�sze narz�dzia wywo�ujemy zazwyczaj w nast�puj�cej kolejno�ci: +Powyższe narzędzia wywołujemy zazwyczaj w następującej kolejności: %{__gettextize} %{__libtoolize} %{__intltoolize} @@ -197,74 +197,74 @@ %{__autoheader} %{__automake} -Je�li kt�ry� z plik�w generowanych przez ac/am/lt/gt wymaga -przebudowania lub od�wie�enia (ew. z wyj�tkiem config.{guess,sub}), -to nale�y przebudowa� ca�o�� tych zasob�w z pakietu; uruchomienie -np. samego autoconfa w programie korzystaj�cym tak�e z automake'a mo�e -powodowa� dziwne b��dy. Cz��ciowe przebudowanie zasob�w dopuszczalne +Jeśli któryś z plików generowanych przez ac/am/lt/gt wymaga +przebudowania lub odświeżenia (ew. z wyjątkiem config.{guess,sub}), +to należy przebudować całość tych zasobów z pakietu; uruchomienie +np. samego autoconfa w programie korzystającym także z automake'a może +powodować dziwne błędy. Częściowe przebudowanie zasobów dopuszczalne jest tylko w uzasadnionych przypadkach opatrzonych komentarzem -wyja�niaj�cym przyczyn�. +wyjaśniającym przyczynę. -W wielu �r�d�ach config.sub jest zbyt stare i mo�e nie rozpoznawa� niekt�rych -architektur. Objawia si� to zwykle komunikatem wyrzucanym przez configure np.: +W wielu źródłach config.sub jest zbyt stare i może nie rozpoznawać niektórych +architektur. Objawia się to zwykle komunikatem wyrzucanym przez configure np.: "machine amd64-pld is not known". W takim przypadku aktualny config.sub bierze -si� z pakietu automake. Dla projekt�w korzystaj�cych z automake wystarczy -przegenerowanie plik�w tak jak podano powy�ej. Jednak z config.sub korzystaj� -tak�e programy nie u�ywaj�ce automake, albo nawet nie u�ywaj�ce autoconf. -W takim przypadku plik nale�y skopiowa� w sekcji %build speca, np. tak: +się z pakietu automake. Dla projektów korzystających z automake wystarczy +przegenerowanie plików tak jak podano powyżej. Jednak z config.sub korzystają +także programy nie używające automake, albo nawet nie używające autoconf. +W takim przypadku plik należy skopiować w sekcji %build speca, np. tak: cp /usr/share/automake/config.sub . -Oczywi�cie nale�y wtedy doda� BuildRequires: automake. +Oczywiście należy wtedy dodać BuildRequires: automake. -Zale�no�ci przy budowaniu pakiet�w: +Zależności przy budowaniu pakietów: -Wszystkie pakiety potrzebne do zbudowania danego pakietu P (opr�cz -nag��wk�w j�dra) powinny by� wymagane jawnie - w jednym z trzech miejsc: +Wszystkie pakiety potrzebne do zbudowania danego pakietu P (oprócz +nagłówków jądra) powinny być wymagane jawnie - w jednym z trzech miejsc: - w BuildRequires w specu do pakietu P - w Requires pakietu rpm-build (globalne wymagania - pakiety potrzebne - przy budowaniu zdecydowanej wi�kszo�ci pakiet�w) -- w Requires pakiet�w wymienionych na dw�ch ww. listach. + przy budowaniu zdecydowanej większości pakietów) +- w Requires pakietów wymienionych na dwóch ww. listach. -Staramy si� nie duplikowa� wymaga� - je�li co� jest wymagane (tak�e -po�rednio) przez rpm-build lub kt�ry� pakiet z listy BuildRequires -pakietu P, nie dopisujemy go ju� do BuildRequires pakietu P - chyba, �e -trzeba zaostrzy� wymaganie co do wersji. - -W przypadku bibliotek dzielonych (i modu��w np. perlowych) linkowanych -dynamicznie w czasie kompilacji trzeba pami�ta�, �eby opr�cz -"BuildRequires: co�tam[-devel] >= wersja" dopisywa� tak�e -"Requires: co�tam >= wersja" - chyba �e zale�no�� taka wynika ju� +Staramy się nie duplikować wymagań - jeśli coś jest wymagane (także +pośrednio) przez rpm-build lub któryś pakiet z listy BuildRequires +pakietu P, nie dopisujemy go już do BuildRequires pakietu P - chyba, że +trzeba zaostrzyć wymaganie co do wersji. + +W przypadku bibliotek dzielonych (i modułów np. perlowych) linkowanych +dynamicznie w czasie kompilacji trzeba pamiętać, żeby oprócz +"BuildRequires: cośtam[-devel] >= wersja" dopisywać także +"Requires: cośtam >= wersja" - chyba że zależność taka wynika już z SONAME (w przypadku bibliotek dzielonych) lub jest generowana -automatycznie (w przypadku modu��w perlowych). +automatycznie (w przypadku modułów perlowych). -Standardowo (bez bcond�w, --nodeps itp.) zale�no�ci przy budowaniu -pakietu P, nak�adane �aty oraz polecenia w specu (opcje do %configure, -zmienne make itp.) powinny jednoznacznie okre�la� mo�liwo�ci -i zale�no�ci budowanego pakietu. Sytuacja, gdy w obecno�ci jakiego� +Standardowo (bez bcondów, --nodeps itp.) zależności przy budowaniu +pakietu P, nakładane łaty oraz polecenia w specu (opcje do %configure, +zmienne make itp.) powinny jednoznacznie określać możliwości +i zależności budowanego pakietu. Sytuacja, gdy w obecności jakiegoś innego pakietu Q (nie wymienionego w BuildRequires ani BuildConflicts) -pakiet P zaczyna wymaga� pakietu Q lub sam z siebie buduje si� -z jakimi� nowymi opcjami, jest niepoprawna. +pakiet P zaczyna wymagać pakietu Q lub sam z siebie buduje się +z jakimiś nowymi opcjami, jest niepoprawna. -Proces budowania pakietu i generowane zale�no�ci powinny by� -przewidywalne - je�li dany pakiet wykrywa pewne komponentu podczas -budowania, i nie jest to kontrolowane za pomoc� n.p. opcji configure, to -taki pakiet mo�na uzna� jako zepsuty i nale�y go naprawi�. +Proces budowania pakietu i generowane zależności powinny być +przewidywalne - jeśli dany pakiet wykrywa pewne komponentu podczas +budowania, i nie jest to kontrolowane za pomocą n.p. opcji configure, to +taki pakiet można uznać jako zepsuty i należy go naprawić. Standardem jest linkowanie dynamiczne (i BuildRequires: biblioteka-devel). -Linkowania statycznego (i BuildRequires: biblioteka-static) mo�na u�ywa� -tylko w dobrze uzasadnionych przypadkach. Stwierdzenie "bo tak by�o -�atwiej" albo "program tak robi domy�lnie" nie jest wystarczaj�cym +Linkowania statycznego (i BuildRequires: biblioteka-static) można używać +tylko w dobrze uzasadnionych przypadkach. Stwierdzenie "bo tak było +łatwiej" albo "program tak robi domyślnie" nie jest wystarczającym uzasadnieniem. -Nale�y te� pami�ta� o ustawianiu odpowiednich Obsoletes/ Provides -w przypadku gdy pakiet zmienia nazw� lub w innych dystrybucjach wyst�puje -pod inn� nazw�. +Należy też pamiętać o ustawianiu odpowiednich Obsoletes/ Provides +w przypadku gdy pakiet zmienia nazwę lub w innych dystrybucjach występuje +pod inną nazwą. -Nie u�ywamy makra %{_sysconfdir} w �cie�kach do sta�ych, -og�lnosystemowych katalog�w: +Nie używamy makra %{_sysconfdir} w ścieżkach do stałych, +ogólnosystemowych katalogów: /etc/cron.* /etc/crontab.d /etc/logrotate.d @@ -275,48 +275,48 @@ /etc/skel /etc/sysconfig -Sekcja przygotowania �r�de� (%prep) -W tej sekcji nast�puje przygotowanie �r�de� do procesu budowania poprzez -rozkompresowanie �r�de�, na�o�enie �atek itp. -W najprostszym przypadku sekcja ta wygl�da: +Sekcja przygotowania źródeł (%prep) +W tej sekcji następuje przygotowanie źródeł do procesu budowania poprzez +rozkompresowanie źródeł, nałożenie łatek itp. +W najprostszym przypadku sekcja ta wygląda: %prep %setup -q -co powoduje rozkompresowanie pliku wskazanego w Source0 i zmian� katalogu -na %{name}-%{version} - gdzie zwykle znajduj� si� �r�d�a pakietu. -W przypadku gdy rozkompresowany katalog nazywa si� inaczej, nazw� katalogu +co powoduje rozkompresowanie pliku wskazanego w Source0 i zmianę katalogu +na %{name}-%{version} - gdzie zwykle znajdują się źródła pakietu. +W przypadku gdy rozkompresowany katalog nazywa się inaczej, nazwę katalogu podajemy przez parametr -n: %prep %setup -q -n %{module}-%{fn_ver} -W przypadku gdy nie pracujemy na skompresowanych �r�d�ach, tylko np. na -�r�d�ach z CVS sekcja mo�e wygl�da� np. tak: +W przypadku gdy nie pracujemy na skompresowanych źródłach, tylko np. na +źródłach z CVS sekcja może wyglądać np. tak: %prep %setup -q -c -T install %{SOURCE0} . install %{SOURCE1} . -Powy�sze tworzy katalog budowania i kopiuje do niego pliki wskazane przez +Powyższe tworzy katalog budowania i kopiuje do niego pliki wskazane przez Source0 i Source1. -W sekcji %prep nie nale�y kopiowa� plik�w z innych pakiet�w, poniewa� -builder -bp ignoruje BuildRequires. Przyk�adowo nast�puj�ca komenda powinna si� -znale�� w sekcji %build: +W sekcji %prep nie należy kopiować plików z innych pakietów, ponieważ +builder -bp ignoruje BuildRequires. Przykładowo następująca komenda powinna się +znaleźć w sekcji %build: cp -f /usr/share/automake/config.sub . -W sekcji %prep nak�adamy �atki na �r�d�a korzystaj�c z makr %patchN. Na -przyk�ad tak: +W sekcji %prep nakładamy łatki na źródła korzystając z makr %patchN. Na +przykład tak: %prep %setup -q %patch0 -p1 %patch1 -p0 -CVS, przynajmniej nasz, automatycznie konwertuje ko�ce linii DOS-owe (\r\n) -na uniksowe (\n). W przypadku �atek taka zmiana cz�sto powoduje, �e po -scommitowaniu �atki a nast�pnie pobraniu, �atka przestaje si� nak�ada�. Nale�y -w takim przypadku przekonwertowa� ko�ce linii w patchowanych plikach, na -przyk�ad tak: +CVS, przynajmniej nasz, automatycznie konwertuje końce linii DOS-owe (\r\n) +na uniksowe (\n). W przypadku łatek taka zmiana często powoduje, że po +scommitowaniu łatki a następnie pobraniu, łatka przestaje się nakładać. Należy +w takim przypadku przekonwertować końce linii w patchowanych plikach, na +przykład tak: %undos build.xml @@ -324,125 +324,125 @@ %undos $(find -name '*.php') -Pami�taj, �eby doda� odpowiednie BR-y dla makra %undos takie, jak opisano w +Pamiętaj, żeby dodać odpowiednie BR-y dla makra %undos takie, jak opisano w pliku BuildRequires.txt. Sekcja budowania (%build): -W tej sekcji nale�y zawrze� wszystko co spowoduje zbudowanie pakietu w +W tej sekcji należy zawrzeć wszystko co spowoduje zbudowanie pakietu w katalogu %{_topdir}/BUILD w drzewie budowania rpma. W sekcji tej katalog -$RPM_BUILD_ROOT nie powinien by� u�ywany. +$RPM_BUILD_ROOT nie powinien być używany. -Wyst�puj�ce kiedy� w tej sekcji redefinicje kde_*: +Występujące kiedyś w tej sekcji redefinicje kde_*: kde_htmldir="%{_htmldir}"; export kde_htmldir kde_icondir="%{_pixmapsdir}"; export kde_icondir kde_appsdir="%{_applnkdir}"; export kde_appsdir -s� przestarza�e (a dwie ostatnie ju� b��dne) i nale�y je usun��, -a w zamian nale�y przedefiniowa� kde_htmldir w sekcji %install: +są przestarzałe (a dwie ostatnie już błędne) i należy je usunąć, +a w zamian należy przedefiniować kde_htmldir w sekcji %install: %{__make} install \ DESTDIR=$RPM_BUILD_ROOT \ kde_htmldir=%{_kdedocdir} -Wyj�tkiem s� pakiety, w kt�rych kde_htmldir jest u�ywane nie tylko przy -instalacji (np. kdelibs) - wtedy redefinicja musi by� w %build "po +Wyjątkiem są pakiety, w których kde_htmldir jest używane nie tylko przy +instalacji (np. kdelibs) - wtedy redefinicja musi być w %build "po staremu". -Nie u�ywamy -qt-st. Jest tylko dla kompatybilno�ci z obcymi programami. -I ewentualnie jakimi� programami maj�cymi problemy z w�tkami, ale takich +Nie używamy -qt-st. Jest tylko dla kompatybilności z obcymi programami. +I ewentualnie jakimiś programami mającymi problemy z wątkami, ale takich jak do tej pory nie stwierdzono. -Je�li podczas budowania wyst�pi b��d "/usr/bin/ld: cannot find -lqt" -nalezy zmieni� -lqt na -lqt-mt (u�ywaj�c opcji configure, zmiennej -�rodowiskowej, �aty lub seda). +Jeśli podczas budowania wystąpi błąd "/usr/bin/ld: cannot find -lqt" +nalezy zmienić -lqt na -lqt-mt (używając opcji configure, zmiennej +środowiskowej, łaty lub seda). Sekcja instalacji (%install): -S�u�y do zawarcia komend instaluj�cych to co zosta�o wybudowane w sekcji -budowania w katalogu $RPM_BUILD_ROOT. Powinna si� rozpoczyna� od +Służy do zawarcia komend instalujących to co zostało wybudowane w sekcji +budowania w katalogu $RPM_BUILD_ROOT. Powinna się rozpoczynać od wyczyszczenia owego katalogu: %install rm -rf $RPM_BUILD_ROOT -Je�eli dana aplikacja zawiera pliki t�umacze� j�zykowych (pliki .mo), -pod koniec tej sekcji u�ywamy makra %find_lang w postaci: +Jeżeli dana aplikacja zawiera pliki tłumaczeń językowych (pliki .mo), +pod koniec tej sekcji używamy makra %find_lang w postaci: %find_lang NAZWA -gdzie NAZWA to nazwa plik�w *.mo bez rozszerzenia (zazwyczaj wystarczy -u�y� %{name}, niekt�re pakiety u�ywaj� r��nej nazwy). Je�li w pakiecie -s� pliki *.mo o r��nych nazwach i wszystkie maj� si� znale�� w tym samym -pakiecie, to mo�na u�y� makra w postaci: +gdzie NAZWA to nazwa plików *.mo bez rozszerzenia (zazwyczaj wystarczy +użyć %{name}, niektóre pakiety używają różnej nazwy). Jeśli w pakiecie +są pliki *.mo o różnych nazwach i wszystkie mają się znaleźć w tym samym +pakiecie, to można użyć makra w postaci: %find_lang %{name} --all-name -Dodatkowo makro %find_lang mo�e obs�u�y� t�umaczenia pomocy z GNOME +Dodatkowo makro %find_lang może obsłużyć tłumaczenia pomocy z GNOME (katalogi %{_datadir}/gnome/help/* - z parametrem --with-gnome) oraz KDE (katalogi %{_docdir}/kde/HTML/* - z parametrem --with-kde). -Makro %find_lang wygeneruje nam list� plik�w, kt�r� do��czamy do sekcji -%files w nast�puj�cy spos�b: +Makro %find_lang wygeneruje nam listę plików, którą dołączamy do sekcji +%files w następujący sposób: %files -f NAZWA.lang -(gdzie NAZWA to nazwa u�yta przy %find_lang). +(gdzie NAZWA to nazwa użyta przy %find_lang). -Budownie rpm�w w PLD musi ko�czy� si� sekcj� czyszczenia (%clean) czyszcz�c� +Budownie rpmów w PLD musi kończyć się sekcją czyszczenia (%clean) czyszczącą $RPM_BUILD_ROOT: %clean rm -rf $RPM_BUILD_ROOT -Ten podzia� nabiera wi�kszego sensu przy tworzeniu plik�w .spec dla du�ych -pakiet�w gdzie czas budowania jest znaczny. Wtedy rozs�dnie jest posi�kowa� <<Diff was trimmed, longer than 597 lines>> ---- CVS-web: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/PLD-doc/devel-hints-pl.txt?r1=1.65&r2=1.66&f=u
_______________________________________________ pld-cvs-commit mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
