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:[EMAIL PROTECTED]">[EMAIL
PROTECTED]</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 <[EMAIL PROTECTED]>:
@@ -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:[EMAIL PROTECTED]:Imie i Nazwisko:[EMAIL
PROTECTED]
+ nasz_login:[EMAIL PROTECTED]:Imię i Nazwisko:[EMAIL
PROTECTED]
</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>
_______________________________________________
pld-cvs-commit mailing list
[email protected]
http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
