PLD-doc: devel-hints-pl.txt - more readable layout
pawelz
pawelz at pld-linux.org
Thu Jun 17 15:09:27 CEST 2010
Author: pawelz Date: Thu Jun 17 13:09:27 2010 GMT
Module: PLD-doc Tag: HEAD
---- Log message:
- more readable layout
---- Files affected:
PLD-doc:
devel-hints-pl.txt (1.67 -> 1.68)
---- Diffs:
================================================================
Index: PLD-doc/devel-hints-pl.txt
diff -u PLD-doc/devel-hints-pl.txt:1.67 PLD-doc/devel-hints-pl.txt:1.68
--- PLD-doc/devel-hints-pl.txt:1.67 Thu Jun 10 14:53:37 2010
+++ PLD-doc/devel-hints-pl.txt Thu Jun 17 15:09:22 2010
@@ -2,7 +2,7 @@
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
+ zajrzyj do odpowiedniej sekcji devel-hints-en.txt. Jeżeli zauważysz
rozbieżność między wersją angielską i polską, popraw, albo przynajmniej
wyraźnie oznacz odpowiednie miejsce.
@@ -10,110 +10,105 @@
to równoległe utrzymywanie dwóch wersji językowych dokumentu. Proszę o
przestrzeganie tej zasady.
-TODO:
- przenieść strukturę devel-hints-en.txt.
-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
-i dyskutowania zmian planowanych.
+ 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.
1. Ogólne zasady
-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.
+ 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.
1.2. Środowisko budowy pakietów
-Pakiet musi się budować z konta zwykłego użytkownika bez dodatkowych
-kombinacji.
+ Pakiet musi się budować z konta zwykłego użytkownika bez dodatkowych
+ kombinacji.
1.3. Kodowanie
-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).
+ 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).
1.4. Sekcja %description
-Zawartość sekcji "description" należy formatować na 70 znaków.
+ Zawartość sekcji "description" należy formatować na 70 znaków.
-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.
- IceWM-a)
-- "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)
+ 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.
+ IceWM-a)
+ - "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)
2. 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.)
+ 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.)
2.1. Nienatywne biblioteki (perl, java, etc)
-Nienatywne biblioteki powinny być nazywane według schematu <język>-<nazwa>.
-Przykłady:
- * dla modułów Perla: perl-nazwa (dla modułów obiektowych zazwyczaj
- nazwa jest postaci Klasa[-Klasa[-Klasa...]]
- * 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.
+ Nienatywne biblioteki powinny być nazywane według schematu <język>-<nazwa>.
+ Przykłady:
+ * dla modułów Perla: perl-nazwa (dla modułów obiektowych zazwyczaj
+ nazwa jest postaci Klasa[-Klasa[-Klasa...]]
+ * 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.
2.2. Natywne biblioteki
-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.
+ 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.
3. Wersje pakietów:
@@ -123,20 +118,21 @@
3.2. Wersja aplikacji a tagi Version i Release
-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)
-Version: 2.0
-%define rel 1
-%define subver rc1
-Release: 0.%{subver}.%{rel}
+ 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)
+
+ Version: 2.0
+ %define rel 1
+ %define subver rc1
+ Release: 0.%{subver}.%{rel}
-W takim przypadku po zmianach speca dla tej samej wersji oprogramowania
-zwiększamy ostatnią liczbę w Release ("0" pozostaje bez zmian!).
+ W takim przypadku po zmianach speca dla tej samej wersji oprogramowania
+ zwiększamy ostatnią liczbę w Release ("0" pozostaje bez zmian!).
3.3 Tag Epoch
@@ -144,460 +140,480 @@
4. Tag Group
-Pakiet musi posiadać zdefiniowane pole Group: zgodnie z packages/rpm.groups
+ Pakiet musi posiadać zdefiniowane pole Group: zgodnie z packages/rpm.groups
5. Paczkowanie zewnętrznych modułów jądra
-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:
-%{?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:
-%{?with_dist_kernel:%requires_releq_kernel_up}
- (dla modułów jądra UP)
-lub
-%{?with_dist_kernel:%requires_releq_kernel_smp}
- (dla modułów jądra SMP)
+ 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:
+
+ %{?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:
+ %{?with_dist_kernel:%requires_releq_kernel_up}
+ (dla modułów jądra UP)
+ lub
+ %{?with_dist_kernel:%requires_releq_kernel_smp}
+ (dla modułów jądra SMP)
6. autotools
6.1. BuildRequires
-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
-libtoolize BuildRequires: libtool
-gettextize BuildRequires: gettext-devel
-autopoint BuildRequires: gettext-autopoint
-intltoolize BuildRequires: intltool
-xml-i18n-toolize BuildRequires: intltool
+ autoconf,autoheader BuildRequires: autoconf
+ automake,aclocal BuildRequires: automake
+ libtoolize BuildRequires: libtool
+ gettextize BuildRequires: gettext-devel
+ autopoint BuildRequires: gettext-autopoint
+ 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:
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
- wersja >= 0:1.4.2-9
- - 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ę
- makro AC_CONFIG_AUX_DIR, to wersja >= 1:1.4.3 (lub 2:1.4e
- w przypadku bibliotek w C++)
+ - 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ą
+ 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ę
+ makro AC_CONFIG_AUX_DIR, to wersja >= 1:1.4.3 (lub 2:1.4e
+ w przypadku bibliotek w C++)
6.2. Używanie autotools w specu
-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
-%{__automake} = automake -a -c -f --foreign
-%{__aclocal} = aclocal
-%{__libtoolize} = libtoolize --copy --force
-%{__intltoolize} = intltoolize --copy --force
-%{__gettextize} = gettextize --copy --force [--intl]
- (+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:
-automake -a -c --foreign
-(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:
-%{__gettextize}
-%{__libtoolize}
-%{__intltoolize}
-%{__aclocal}
-%{__autoconf}
-%{__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
-jest tylko w uzasadnionych przypadkach opatrzonych komentarzem
-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.:
-"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:
+ %{__autoconf} = autoconf
+ %{__autoheader} = autoheader
+ %{__automake} = automake -a -c -f --foreign
+ %{__aclocal} = aclocal
+ %{__libtoolize} = libtoolize --copy --force
+ %{__intltoolize} = intltoolize --copy --force
+ %{__gettextize} = gettextize --copy --force [--intl]
+ (+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:
+
+ automake -a -c --foreign
+
+ (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:
+ %{__gettextize}
+ %{__libtoolize}
+ %{__intltoolize}
+ %{__aclocal}
+ %{__autoconf}
+ %{__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 jest tylko w uzasadnionych
+ przypadkach opatrzonych komentarzem 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.: "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:
-cp /usr/share/automake/config.sub .
+ cp /usr/share/automake/config.sub .
-Oczywiście należy wtedy dodać BuildRequires: automake.
+ Oczywiście należy wtedy dodać BuildRequires: automake.
7. 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:
-- 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.
-
-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).
-
-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.
-
-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
-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ą.
+ 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.
+
+ 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).
+
+ 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.
+
+ 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
+ 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ą.
8. Makro %_sysconfdir
-Nie używamy makra %{_sysconfdir} w ścieżkach do stałych,
-ogólnosystemowych katalogów:
-/etc/cron.*
-/etc/crontab.d
-/etc/logrotate.d
-/etc/pam.d
-/etc/profile.d
-/etc/rc.d
-/etc/security
-/etc/skel
-/etc/sysconfig
+ Nie używamy makra %{_sysconfdir} w ścieżkach do stałych, ogólnosystemowych
+ katalogów:
+ /etc/cron.*
+ /etc/crontab.d
+ /etc/logrotate.d
+ /etc/pam.d
+ /etc/profile.d
+ /etc/rc.d
+ /etc/security
+ /etc/skel
+ /etc/sysconfig
9. 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
-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:
-%prep
-%setup -q -c -T
-install %{SOURCE0} .
-install %{SOURCE1} .
-
-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:
-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:
-
-%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:
+ 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:
-%undos build.xml
+ %prep
+ %setup -q
-albo
+ 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:
<<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.67&r2=1.68&f=u
More information about the pld-cvs-commit
mailing list