PLD-doc: devel-hints-pl.txt - utf8
glen
glen at pld-linux.org
Mon Jun 7 16:53:58 CEST 2010
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± pld-devel-pl at lists.pld-linux.org (w jêzyku
-polskim) i pld-devel-en at lists.pld-linux.org (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ą pld-devel-pl at lists.pld-linux.org (w języku
+polskim) i pld-devel-en at lists.pld-linux.org (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
More information about the pld-cvs-commit
mailing list