PLD-doc/book/pl_book__devel/pl_devel__podstawy.chp
zboczuch
cvs w pld-linux.org
Śro, 13 Lip 2005, 14:10:14 CEST
Author: zboczuch
Date: Wed Jul 13 14:10:12 2005
New Revision: 6218
Modified:
PLD-doc/book/pl_book__devel/pl_devel__podstawy.chp
Log:
- hm... lack of E_WITH_OGONEK letter?
- na razie
Modified: PLD-doc/book/pl_book__devel/pl_devel__podstawy.chp
==============================================================================
--- PLD-doc/book/pl_book__devel/pl_devel__podstawy.chp (original)
+++ PLD-doc/book/pl_book__devel/pl_devel__podstawy.chp Wed Jul 13 14:10:12 2005
@@ -39,7 +39,7 @@
Największą skarbnicą wiedzy o RPMie i budowaniu pakietów możemy znaleźć w publikacji
<ulink url="http://developer-doc.pld-linux.org/maximum%20rpm/index.htm">Maximum RPM</ulink> - opis jest w języku angielskim i nie jest mi znane tłumaczenie na nasz język. Na szczęście są jeszcze inne źródełka, a także i niniejszy opis - więc powinno nam być lżej przyswajać wiedzę. Szczególnie polecam stronę
<ulink url="http://lubuska.zapto.org/~hoppke/too_much_to_learn/rpm/index.html">Grzegorza Niewęgłowskiego</ulink> (lub
- <ulink url="http://developer-doc.pld-linux.org/hoppke/too_much_to_learn/rpm/index.htm">lokalną kopie)</ulink> gdzie dużo teorii i praktycznych rad może nam rozjaśnić w naszych głowach czym jest praca ze "specami".
+ <ulink url="http://developer-doc.pld-linux.org/hoppke/too_much_to_learn/rpm/index.htm">lokalną kopię)</ulink> gdzie dużo teorii i praktycznych rad może nam rozjaśnić w naszych głowach czym jest praca ze "specami".
</para>
<para>
Jest dostępny także
@@ -47,7 +47,7 @@
lecz z tego co się dowiedziałem jest już trochę leciwy i niektóre dane mogą być nieścisłe.
</para>
<para>
- Po tej bombie teorii jaką niestety musimy przejść, czeka nas przestudiowanie jeszcze jednego dokumentu, którego najnowszą wersje możemy ściągnąć z CVS PLD. Będzie to nasze pierwsze ćwiczenie.
+ Po tej bombie teorii jaką niestety musimy przejść, czeka nas przestudiowanie jeszcze jednego dokumentu, którego najnowszą wersję możemy ściągnąć z CVS PLD. Będzie to nasze pierwsze ćwiczenie.
</para>
<para>
Uruchamiamy terminal (czy to zwykły, czy też np. przez SSH) i wykonujemy kroki:
@@ -398,7 +398,7 @@
To wtedy stała '_mantisdir' miała by wartość /home/httpd/html/mantis, mimo że nie taka jest nasz intencja - Nie muszę chyba wyjaśniać jakie to może spowodować problemy?
</para>
<para>
- W '%description' opisujemy krótko charakterystykę pakietu, a niżej widzimy jak to zrobić dla opisu w języku polskim - później RPM wykorzystując zmienne locale wyświetla odpowiednią wersje językową 'description' gdy sobie tego od RPMa życzymy.
+ W '%description' opisujemy krótko charakterystykę pakietu, a niżej widzimy jak to zrobić dla opisu w języku polskim - później RPM wykorzystując zmienne locale wyświetla odpowiednią wersję językową 'description' gdy sobie tego od RPMa życzymy.
</para>
<screen>[...]
@@ -584,7 +584,7 @@
Teraz możemy szukać kogoś, kto umieści naszego .speca i źródła w repozytorium CVS PLD. Mamy do dyspozycji listę developerów: w mailu umieszczając załącznik z naszym .specem (oczywiście bez źródeł - lub jeżeli mamy jakieś własne źródła to umieszczamy je na jakieś stronie WWW lub innym ftp. i podajemy linka - źródła natywne powinny dać się ściągnąć z lokacji jaką umieściliśmy w naszym .specu.). Załącznik powinien być typu plain-text.
</para>
<para>
- Można także spróbować na grupie IRC #PLD znaleźć ofiarę, która umieści naszą prace w repozytorium.
+ Można także spróbować na grupie IRC #PLD znaleźć ofiarę, która umieści naszą pracę w repozytorium.
</para>
<para>
Dobrze też w czasie nauki robienia .speców podglądać jak to robią inni - W repozytorium CVS jest naprawdę z czego wybierać. A my nabywając umiejętność czytania plików .spec możemy skupić się już tylko na odpowiednim ich napisaniu.
@@ -622,7 +622,7 @@
konfliktów.
</para>
<para>
- Kiedy już zostaniemy przyjęci, musimy wymyśleć sobie ksywke i hasło. Potem z linii poleceń wykonujemy jednolinijkowe polecenie - wstawiając za <emphasis>login</emphasis> i <emphasis>haslo</emphasis> odpowiednie dane:
+ Kiedy już zostaniemy przyjęci, musimy wymyśleć sobie ksywkę i hasło. Potem z linii poleceń wykonujemy jednolinijkowe polecenie - wstawiając za <emphasis>login</emphasis> i <emphasis>haslo</emphasis> odpowiednie dane:
</para>
<para>
<command>perl -e 'print "</command><emphasis>login</emphasis><command>:" . crypt("</command><emphasis>haslo</emphasis><command>", join "", (".", "/", 0..9, "A".."Z", "a".."z")[rand 64, rand 64]) . "\n"'</command>
@@ -638,7 +638,7 @@
<ulink url="mailto:cvsadmin w pld-linux.org">cvsadmin w pld-linux.org</ulink>
</para>
<para>
- To narazie wszystko co możemy zrobić - trzeba czekać na odpowiedź od władzy CVS. Po kilku, kilkunastu lub kilkudziesięciu dniach przyjdzie mail z odpowiedzią. U mnie była to wiadomość podobna do:
+ To na razie wszystko co możemy zrobić - trzeba czekać na odpowiedź od władzy CVS. Po kilku, kilkunastu lub kilkudziesięciu dniach przyjdzie mail z odpowiedzią. U mnie była to wiadomość podobna do:
</para>
<screen>Quoting Marek Ciesielski <marekc w adres.email>:
@@ -653,13 +653,13 @@
--
Admin CVS <imię i nazwisko> :)</screen>
<para>
- Czyli pierwsze formalności mamy za sobą. Możemy już działać na CVS. Jednak proponuje znowu trochę teorii - tym razem zdecydowana większość dokumentacji jest w języku angielskim. Mamy więc bardzo dobry,
+ Czyli pierwsze formalności mamy za sobą. Możemy już działać na CVS. Jednak proponuję znowu trochę teorii - tym razem zdecydowana większość dokumentacji jest w języku angielskim. Mamy więc bardzo dobry,
<ulink url="http://developer-doc.pld-linux.org/cvs_official_eng/cederqvist-1.11.6.html">oficjalny podręcznik CVS</ulink> (uwaga ponad 800KB),
- <ulink url="http://developer-doc.pld-linux.org/cvs_book/cvsbook.html">książke kucharską CVS</ulink> (uwaga ponad 600KB) - jest także
+ <ulink url="http://developer-doc.pld-linux.org/cvs_book/cvsbook.html">książkę kucharską CVS</ulink> (uwaga ponad 600KB) - jest także
<ulink url="http://developer-doc.pld-linux.org/cvs_pld/cvs_pld.html">opis po polsku</ulink> - stworzony przez developerów PLD, a także książka z cyklu leksykon kieszonkowy "CVS" Gregor N. Purdy (koszt ok. 10PLN) - tak więc jest w czym wybierać.
</para>
<para>
- Jeszcze raz zwróćmy uwagę na maila którego otrzymaliśmy. Jest tam coś o dopisaniu "users". Musimy wykonać zalecenie. Aby to zrobić musimy znowu przygotować sobie środowisko CVS - albo modyfikując istniejące, dotychczasowe konto "anonymous" albo tworząc od początku środowsko w nowym katalogu. Ja wybrałem pierwszy sposób (troche wbrew zaleceniom z dokumentacji - ale za to szybszy), polega on na modyfikacji każdego pliku "Root" w podkatalogach "CVS" - należy tam wpisać fraze:
+ Jeszcze raz zwróćmy uwagę na maila którego otrzymaliśmy. Jest tam coś o dopisaniu "users". Musimy wykonać zalecenie. Aby to zrobić musimy znowu przygotować sobie środowisko CVS - albo modyfikując istniejące, dotychczasowe konto "anonymous" albo tworząc od początku środowsko w nowym katalogu. Ja wybrałem pierwszy sposób (trochę wbrew zaleceniom z dokumentacji - ale za to szybszy), polega on na modyfikacji każdego pliku "Root" w podkatalogach "CVS" - należy tam wpisać frazę:
</para>
<para>
<command>:pserver:<nasz_login>@cvs.pld-linux.org:/cvsroot</command>
@@ -668,7 +668,7 @@
Czyli w naszym przypadku wchodzimy do katalogu ./rpm i wchodzimy do każdego podkatalogu "CVS" i zmieniamy ręcznie plik "Root" - nie ma w tej chwili tych katalogów wiele, więc nie powinno to sprawić kłopotu.
</para>
<para>
- Proponuje także poustawiać sobie zmienne CVS np. CVSEDITOR itp. (szczegóły - oczywiście dokumentacja).
+ Proponuję także poustawiać sobie zmienne CVS np. CVSEDITOR itp. (szczegóły - oczywiście dokumentacja).
</para>
<para>
Następnie możemy już spróbować zalogować się do CVS PLD:
@@ -690,7 +690,7 @@
Do naszego lokalnego repozytorium, do katalogu CVSROOT ściągneliśmy plik users, który służy w PLD do wpisania aliasu pocztowego - przy okazji możemy zobaczyć w jakim towarzystwie przyjdzie nam pracować :)
</para>
<para>
- nasz_login:użytkownik_mail w domena_naszego_email:Imie i Nazwisko:user w jabber.domena
+ nasz_login:użytkownik_mail w domena_naszego_email:Imię i Nazwisko:user w jabber.domena
</para>
<para>
Ostatnie pole jest opcjonalne - wypełniamy je tylko jeśli posiadamy swój własny JID (o ile go posiadamy). Jeśli z różnych przyczyn nie korzystamy z Jabbera - omijamy tę część i zatrzymujemy się na imieniu i nazwisku. Dla zainteresowanych - istnieje oficjalny serwer Jabbera projektu PLD Linux - konta na nim zakłada Mariusz Mazur.
@@ -722,7 +722,7 @@
Właśnie dokonaliśmy pierwszej zmiany w repozytorium PLD. Od tej chwili każdy mail adresowany na <nasz_login>@pld-linux.org trafi na naszą skrzynkę pocztową.
</para>
<para>
- Dalsza część naszych rozważań będzie już w formie konkretnych przykładów, ponieważ to co chcemy zrobić w repozytorium CVS PLD zależy od konkretnych potrzeb. Od tej chwili nikt już nas za rączke nie będzie prowadził, a czekają nas pot, krew, łzy i pierwsze "recenzje" naszych poczynań - np. na grupie PLD-devel czy kanale #PLD - a jedynymi nagrodami będzie brak tych recenzji, zdobyta wiedza, satysfakcja i działające paczki, których przez chwilę nikt na świecie nie będzie miał :)
+ Dalsza część naszych rozważań będzie już w formie konkretnych przykładów, ponieważ to co chcemy zrobić w repozytorium CVS PLD zależy od konkretnych potrzeb. Od tej chwili nikt już nas za rączkę nie będzie prowadził, a czekają nas pot, krew, łzy i pierwsze "recenzje" naszych poczynań - np. na grupie PLD-devel czy kanale #PLD - a jedynymi nagrodami będzie brak tych recenzji, zdobyta wiedza, satysfakcja i działające paczki, których przez chwilę nikt na świecie nie będzie miał :)
</para>
</section>
<section id="devel_dodaj_cvs">
@@ -735,7 +735,7 @@
cvs server: use 'cvs commit' to add this file permanently
$</screen>
<para>
- Jak widać z komentarza, aby zakończyć dodanie pliku należy zatwierdzić zmianę za pomocą polecenia "cvs ci" (polecenia podaje w formie skróconej) - Samo zatwierdzanie (commit) robiliśmy już wcześniej przy okazji pliku "users".
+ Jak widać z komentarza, aby zakończyć dodanie pliku należy zatwierdzić zmianę za pomocą polecenia "cvs ci" (polecenia podaję w formie skróconej) - Samo zatwierdzanie (commit) robiliśmy już wcześniej przy okazji pliku "users".
</para>
</section>
<section id="devel_aktualizuj_cvs">
@@ -750,7 +750,7 @@
P python.spec
$</screen>
<para>
- W powyższym przykładzie dokonaliśmy aktualizacji pliku "python.spec". Literka "P" określa stan aktualizacji. Poniżej przedstawie możlwe kody:
+ W powyższym przykładzie dokonaliśmy aktualizacji pliku "python.spec". Literka "P" określa stan aktualizacji. Poniżej przedstawię możlwe kody:
</para>
<itemizedlist>
<listitem><para>"A" - Plik dodany. Oznacza że na pliku dokonano operacji "ADD" (czyli dodanie do repozytorium) ale nie wykonano commitu (zatwierdzenia)</para></listitem>
@@ -771,7 +771,7 @@
<para>
Jednak chciałbym zwrócić uwagę na inny sposób składowania źródeł natywnych. W pewnym momencie okazuje się, że składowanie wszystkich plików w repozytorium CVS jest mało efektywne i powoduje zbyt duże obciążenia serwerów. Dlatego też w PLD zastosowano mechanizm
<ulink url="http://developer-doc.pld-linux.org/distfiles/distfiles.htm">Distfiles</ulink> którego krótki opis możemy odszukać
- <ulink url="http://developer-doc.pld-linux.org/distfiles/distfiles.htm">tu</ulink>. W wielkim skrócie oznacza to że preparując odpowiednio spec (pamiętacie tajemnicze md5?) i korzystając z odpowiednich opcji programu ./builder możemy sterować ściąganiem plików do distfiles. Tak naprawdę najczęściej wykorzystane są dwie opcje ./builder - "5" i "U". Jest to także powód używania programu ./builder (a nie frazy "rpmbuild -ba"), którego kopie najlepiej ściągnąć z CVS. Pamiętajmy także o tym, że w systemie istnieje inny builder, który jest dostarczany z narzędziami rpm ale oczywiście nie ma on możliwości pracy z distfiles. I jeszcze jedna uwaga: Distfiles jest przeznaczony tylko dla źródeł natywnych - wszelkie patche i nasze pliki dodajemy normalnie do CVS (najczęściej do katalogu SOURCES).
+ <ulink url="http://developer-doc.pld-linux.org/distfiles/distfiles.htm">tu</ulink>. W wielkim skrócie oznacza to że preparując odpowiednio spec (pamiętacie tajemnicze md5?) i korzystając z odpowiednich opcji programu ./builder możemy sterować ściąganiem plików do distfiles. Tak naprawdę najczęściej wykorzystane są dwie opcje ./builder - "5" i "U". Jest to także powód używania programu ./builder (a nie frazy "rpmbuild -ba"), którego kopię najlepiej ściągnąć z CVS. Pamiętajmy także o tym, że w systemie istnieje inny builder, który jest dostarczany z narzędziami rpm ale oczywiście nie ma on możliwości pracy z distfiles. I jeszcze jedna uwaga: Distfiles jest przeznaczony tylko dla źródeł natywnych - wszelkie patche i nasze pliki dodajemy normalnie do CVS (najczęściej do katalogu SOURCES).
</para>
<para>
Oto przykłady użycia <command>./builder</command> z odpowiednimi opcjami:
@@ -815,7 +815,7 @@
W każdym większym CVSie, projekty główne rozgałęziają się tworząc tzw. branche - W przypadku PLD np. istnieje stabilny, lecz już troche leciwy branch "RA-branch", który wywodzi się z brancha głównego HEAD. W pewnym momencie RA-branch został "zamrożony" i dokonywane są na nim tylko zmiany zawierające poprawki poważnych błędów lub aktualizacje związane z bezpieczeństwem. Branch HEAD "żyje" dalej i są w nim dokonywane zmiany i powstają nowe pakiety. Odgałęzień może być (i jest) wiele, co na początku troche gmatwa spojrzenie na CVS ale później doceniamy zalety tego rozwiązania. Dane odnogi mają przydzielone odpowiednie etykiety "lepkie" (ang. sticky tag) - czyli etykieta jest przekazywana każdej następnej wersji w danej odnodze. Zwykłe etykiety (ang. tag) możemy użyć np. do okreslenia indywidualnego stanu danego pliku - określając np. tag STABLE, UNSTABLE lub DEVELOP.
</para>
<para>
- Jeżeli chodzi o etykietowanie to trzeba zachować rozwagę. Musimy być pewni że wiemy co chcemy osiągnąć, bo możemy popsuć prace komuś innemu (dotyczy to także zmian w cudzych specach).
+ Jeżeli chodzi o etykietowanie to trzeba zachować rozwagę. Musimy być pewni że wiemy co chcemy osiągnąć, bo możemy popsuć pracę komuś innemu (dotyczy to także zmian w cudzych specach).
</para>
<para>
Praktycznie najczęściej wykorzystywane są następujące opcje związane z odnogami i etykietami:
@@ -884,7 +884,7 @@
<section id="devel_zakonczenie_cvs">
<title>Zakończenie</title>
<para>
- Zbliżamy się do końca naszego praktycznego poradnika. Nie zostało poruszonych wiele kwestii, które wyjdą w codziennej pracy. Dlatego mamy do pomocy dokumentacje, listy dyskusyjne, IRC, zasoby CVS i przeglądarkę GOOGLE ;). Praca ta miała na celu wprowadzić w świat pracy developerskiej i pokazać praktyczne rozwiązania niektórych problemów - reszta zależy od naszej wiedzy i pracowitości - i pamiętajmy, że najważniejsze to rozwijać swoje zdolności, bo od tego zależy nasza przyszłość i przyszłość projektu dla którego pracujemy :)
+ Zbliżamy się do końca naszego praktycznego poradnika. Nie zostało poruszonych wiele kwestii, które wyjdą w codziennej pracy. Dlatego mamy do pomocy dokumentację, listy dyskusyjne, IRC, zasoby CVS i przeglądarkę GOOGLE ;). Praca ta miała na celu wprowadzić w świat pracy developerskiej i pokazać praktyczne rozwiązania niektórych problemów - reszta zależy od naszej wiedzy i pracowitości - i pamiętajmy, że najważniejsze to rozwijać swoje zdolności, bo od tego zależy nasza przyszłość i przyszłość projektu dla którego pracujemy :)
</para>
</section>
</chapter>
Więcej informacji o liście dyskusyjnej pld-doc