User Tools

Site Tools


pl:developingpld

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
pl:developingpld [2008-07-26 08:11]
grizz specs-todo from wiki added
pl:developingpld [2013-10-29 18:24] (current)
draenog [Infrastruktura PLD]
Line 12: Line 12:
  
   * Podstawowe operacje ''​rpm'' ​   * Podstawowe operacje ''​rpm'' ​
-  * Korzystanie z systemów kontroli wersji takich jak ''​cvs''​ czy ''​svn'' ​+  * Korzystanie z systemów kontroli wersji takich jak ''​git''​ czy ''​svn'' ​
   * Obsługa różnic między plikami w oparciu o ''​diff''​ i ''​patch'' ​   * Obsługa różnic między plikami w oparciu o ''​diff''​ i ''​patch'' ​
   * Kompilowanie oprogramowania ze źródeł ​   * Kompilowanie oprogramowania ze źródeł ​
Line 20: Line 20:
 W porównaniu do innych dużych dystrybucji,​ PLD Linux nie ma komercyjnego wsparcia. Społeczność deweloperów składa się z ludzi, którzy po prostu potrzebują wykonać jakąś pracę, albo czerpią przyjemność z uczestniczenia w tym, otwartym projekcie (często oba powody są równie istotne). ​ W porównaniu do innych dużych dystrybucji,​ PLD Linux nie ma komercyjnego wsparcia. Społeczność deweloperów składa się z ludzi, którzy po prostu potrzebują wykonać jakąś pracę, albo czerpią przyjemność z uczestniczenia w tym, otwartym projekcie (często oba powody są równie istotne). ​
  
-W swoich wewnętrznych strukturach PLD jest podzielone na linie dystrybucyjne. Aktualnie istnieją trzy:  +W swoich wewnętrznych strukturach PLD jest podzielone na niezależne ​linie dystrybucyjne, dla każdej z [[:About|wersji ​PLD]]. Każdą linią zarządza osoba zwana kierownikiem wydania (Release Manager). RM zajmuje się utrzymywaniem części infrastruktury PLD, podejmowaniem decyzji, w momencie kiedy deweloperzy sami nie mogą rozstrzygnąć jakiejś kwestii i opiekowaniem się zawartością serwera FTP.  ​
- +
- +
-  * PLD Ra/1.0 (wydana jakiś czas temu)  +
-  * [[:AcInfo|PLD Ac/2.0]] (stabilna)  +
-  * [[:​ThInfo|PLD Th/3.0]] (rozwijana)  +
-Każdą linią zarządza osoba zwana kierownikiem wydania (Release Manager). RM zajmuje się utrzymywaniem części infrastruktury PLD, podejmowaniem decyzji, w momencie kiedy deweloperzy sami nie mogą rozstrzygnąć jakiejś kwestii i opiekowaniem się zawartością serwera FTP.  ​+
  
 Inaczej niż RM, większość deweloperów zajmuje się głównie utrzymywaniem pakietów, co zazwyczaj oznacza pracę z plikami ''​spec''​ (będą one wyjaśnione później). Nie ma tutaj wymuszonej odpowiedzialności i każdy może działać z jakimkolwiek pakietem. Jedyną zasadą jest //dotykaj się czegoś, tylko wtedy gdy, jesteś pewien, że wiesz co robisz//. Innymi słowy ludzie nie wybierają pakietów do pracy losowo, ale zajmują się tymi, których potrzebują. Może to wyglądać trochę chaotycznie,​ ale ten model jest całkiem stabilny, ponieważ każda zmiana jest niemal natychmiast weryfikowana. Nie trzeba chyba zaznaczać, że deweloperzy przepadają za takim sposobem organizacji,​ bo nie potrzebują niczyjej zgody, aby wprowadzać zmiany, których potrzebują.  ​ Inaczej niż RM, większość deweloperów zajmuje się głównie utrzymywaniem pakietów, co zazwyczaj oznacza pracę z plikami ''​spec''​ (będą one wyjaśnione później). Nie ma tutaj wymuszonej odpowiedzialności i każdy może działać z jakimkolwiek pakietem. Jedyną zasadą jest //dotykaj się czegoś, tylko wtedy gdy, jesteś pewien, że wiesz co robisz//. Innymi słowy ludzie nie wybierają pakietów do pracy losowo, ale zajmują się tymi, których potrzebują. Może to wyglądać trochę chaotycznie,​ ale ten model jest całkiem stabilny, ponieważ każda zmiana jest niemal natychmiast weryfikowana. Nie trzeba chyba zaznaczać, że deweloperzy przepadają za takim sposobem organizacji,​ bo nie potrzebują niczyjej zgody, aby wprowadzać zmiany, których potrzebują.  ​
Line 36: Line 30:
  
 ==== Pliki spec ==== ==== Pliki spec ====
-Plik ''​spec'' ​zawiera metadane i instrukcje budowania wymagane do stworzenia przynajmniej jednego pakietu RPM. Jest to plik tekstowy przeznaczony do pracy skryptu ''​builder'',​ który z kolei obsługuje cały proces, od skompletowania wszystkich niezbędnych źródeł z infrastruktury PLD (lub bezpośrednio z Internetu), do pakowania wyników w instalowalny plik RPM (druga część jest wykonywana przez narzędzie ''​rpmbuild''​). ​+Plik [[http://​www.rpm.org/​max-rpm/​ch-rpm-inside.html|spec]] zawiera metadane i instrukcje budowania wymagane do stworzenia przynajmniej jednego pakietu RPM. Jest to plik tekstowy przeznaczony do pracy skryptu ''​builder'',​ który z kolei obsługuje cały proces, od skompletowania wszystkich niezbędnych źródeł z infrastruktury PLD (lub bezpośrednio z Internetu), do pakowania wyników w instalowalny plik RPM (druga część jest wykonywana przez narzędzie ''​rpmbuild''​). ​
  
-Możesz także [[http://www.rpm.org/max-rpm/ch-rpm-inside.html|poczytać więcej o plikach spec]]. +Pliki ''​spec''​ rezydują w podkatalogach poszczególnych pakietów wewnątrz katalogu ​//packages// naszego [[:​pl:​Repositoriesserwera git]]. 
  
-Wszystkie pliki ''​spec''​ rezydują wewnątrz modułu //SPEC// naszego [[:​Repositories| serwera CVS]]. Moduł ten zawiera także inne specjalne pliki, najbardziej istotny jest skrypt ''​builder''​. ​ 
  
  
 +==== Distfiles - źródła w postaci binarnej ====
 +Distfiles to serwer FTP/HTTP, służący do przechowywania plików binarnych, np. spakowanych źródeł programów. Dokonując zmiany w SPECU, automat pobiera plik, wskazany w polu SourceX pliku spec, następnie umieszcza go na serwerze. Dzięki temu budowane pakiety będą pobierane zawsze z tego serwera. Archiwa ze źródłami,​ których nie obsłuży ten automat - np. źródła pobrane z systemu kontroli wersji, muszą być umieszczane osobiście przez dewelopera przy każdej ich zmianie. Więcej o [[http://​cvs.pld-linux.org/​cgi-bin/​viewvc.cgi/​cvs/​PLD-doc/​Distfiles-Quick-HowTo?​view=markup|distfiles]]. ​
  
-==== Skrypt builder ==== 
-Skrypt ''​builder''​ jest odpowiedzialny za cały proces montowania pakietu. Zbiera wszystkie potrzebne źródła, sprawdza wymagane zależności,​ rozpakowuje źródła, kompiluje je i na końcu pakuje rezultaty w instalowalny plik RPM.  
  
-Możesz także ​[[:​pl:​DevelopingPLD:​BuilderScript|poczytać więcej o skrypcie ​builder]]. ​+ 
 +==== Źródła w git ==== 
 +Łatki źródeł programów (trzymanych w distfiles), init-skrypty i źródła innych plików koniecznych do budowania pakietów, są przechowywane w git w katalogu pakietu.  
 + 
 + 
 + 
 +==== Skrypt builder ==== 
 +Skrypt ​[[:​pl:​DevelopingPLD:​BuilderScript|builder]] ​jest odpowiedzialny za cały proces montowania pakietu. Zbiera wszystkie potrzebne źródła, sprawdza wymagane zależności,​ rozpakowuje źródła, kompiluje je i na końcu pakuje rezultaty w instalowalny plik RPM
  
 Skrypt ten może zostać uruchomiony przez użytkownika w specjalnej strukturze katalogów w katalogu domowym użytkownika i w znacznym stopniu jest zależny od programu ''​rpmbuild''​ dostarczanego przez pakiet ''​rpm-build''​. ​ Skrypt ten może zostać uruchomiony przez użytkownika w specjalnej strukturze katalogów w katalogu domowym użytkownika i w znacznym stopniu jest zależny od programu ''​rpmbuild''​ dostarczanego przez pakiet ''​rpm-build''​. ​
Line 58: Line 58:
 Skrypt ''​adapter''​ jest narzędziem mającym pomóc deweloperowi w procesie tworzenia czystych plików ''​spec''​. Wykonuje on automatycznie szereg czynności czyszczących i zajmuje się częstymi błędami pojawiającymi się w plikach ''​spec''​. ​ Skrypt ''​adapter''​ jest narzędziem mającym pomóc deweloperowi w procesie tworzenia czystych plików ''​spec''​. Wykonuje on automatycznie szereg czynności czyszczących i zajmuje się częstymi błędami pojawiającymi się w plikach ''​spec''​. ​
  
-PLD jest bardzo restrykcyjne jeżeli chodzi o pliki ''​spec'',​ więc zaleca się aby korzystać ze skryptu adaptującego w przypadku każdego pliku wysyłanego na listę mailingową deweloperów czy dodawanych do [[:​Repositories| repozytorium]]. ​+PLD jest bardzo restrykcyjne jeżeli chodzi o pliki ''​spec'',​ więc zaleca się aby korzystać ze skryptu adaptującego w przypadku każdego pliku wysyłanego na listę mailingową deweloperów czy dodawanych do [[:pl:​Repositories| repozytorium]]. ​
  
 Możesz także [[:​pl:​DevelopingPLD:​AdapterScript|poczytać więcej o skrypcie adaptującym]]. ​ Możesz także [[:​pl:​DevelopingPLD:​AdapterScript|poczytać więcej o skrypcie adaptującym]]. ​
Line 65: Line 65:
  
 ==== Infrastruktura PLD ==== ==== Infrastruktura PLD ====
-Cały proces tworzenia pakietów odbywa się dzięki klasterowi maszyn budujących pliki RPM z odpowiadających im plików ''​spec''​. Każda jednostka ma swóje ​przeznaczenie. Niektóre budują pakiety na konkretne architektury,​ a inne tworzą pakiety src.rpm zawierające wszystko co jest potrzebne do budowy danego pakietu. Są też węzły służące deweloperom jako środowisko testowe do budowania i sprawdzania pakietów. ​+Cały proces tworzenia pakietów odbywa się dzięki klasterowi maszyn budujących pliki RPM z odpowiadających im plików ''​spec''​. Każda jednostka ma swoje przeznaczenie. Niektóre budują pakiety na konkretne architektury,​ a inne tworzą pakiety src.rpm zawierające wszystko co jest potrzebne do budowy danego pakietu. Są też węzły służące deweloperom jako środowisko testowe do budowania i sprawdzania pakietów. ​
  
 Możesz także [[:​Machines| poczytać więcej o komputerach PLD]]. ​ Możesz także [[:​Machines| poczytać więcej o komputerach PLD]]. ​
Line 71: Line 71:
 Każda linia dystrybucji ma swój własny zestaw narzędzi do tworzenia pakietów, i własną kolejkę budowania zarządzaną przez grupę zaufanych deweloperów. ​ Każda linia dystrybucji ma swój własny zestaw narzędzi do tworzenia pakietów, i własną kolejkę budowania zarządzaną przez grupę zaufanych deweloperów. ​
  
-[[:pl:​DevelopingPLD:​ThRequestsRules|Zasady wysyłania żądań do budowania pakietów PLD 3.0 (Th) ]]. +[[:​DevelopingPLD:​ThRequestsRules| Zasady wysyłania żądań do budowania pakietów PLD 3.0 (Th) ]].  
 + 
 +[[:​DevelopingPLD:​AcRequestsRules| Zasady wysyłania żądań do budowania pakietów PLD 2.0 (Ac) ]]. 
  
-[[:pl:​DevelopingPLD:​AcRequestsRules|Zasady wysyłania żądań do budowania pakietów ​PLD 2.0 (Ac) ]]. +[[http://​ep09.pld-linux.org/​~builderth/​queue.html|Kolejka builderów ​PLD 3.0 (Th)]].
  
  
Line 83: Line 85:
 Powinieneś zacząć od zapisania się na przynajmniej jedną z naszych [[:​MailingLists| list mailingowych]]. Zwłaszcza na ''​pld-devel-en''​ (lub ''​pl''​ dla polskich deweloperów),​ a także na ''​pld-discuss''​ przeznaczoną na różne dyskusje związane z dystrybucją. ​ Powinieneś zacząć od zapisania się na przynajmniej jedną z naszych [[:​MailingLists| list mailingowych]]. Zwłaszcza na ''​pld-devel-en''​ (lub ''​pl''​ dla polskich deweloperów),​ a także na ''​pld-discuss''​ przeznaczoną na różne dyskusje związane z dystrybucją. ​
  
-Zauważ, że istnieje także specjalna lista ''​pld-cvs-commit'',​ która nie jest przeznaczona do dyskusji. Zbiera ona natomiast informacje o wszystkich zmianach wprowadzanych przez innych deweloperów na stronie www, czy w repozytorium ​CVS i SVN. +Zauważ, że istnieje także specjalna lista ''​pld-cvs-commit'',​ która nie jest przeznaczona do dyskusji. Zbiera ona natomiast informacje o wszystkich zmianach wprowadzanych przez innych deweloperów na stronie www, czy w repozytoriach git, CVS i SVN. 
  
  
Line 93: Line 95:
  
 ==== Praca nad pakietami ==== ==== Praca nad pakietami ====
-Zacznij od prostych rzeczy. Wybranie losowego pakietu i aktualizowanie go, może wydawać się dobrym pomysłem, ale w ten sposób prędzej sprowadzisz na siebie kłopoty. Zepsucie aplikacji, od której zależą inne pakiety, nie zaszkodzi dystrybucji samej w sobie, ale zdenerwuje ludzi i utrudni ci dalszą pracę. Spróbuj dodać plik ''​spec'' ​dla małej aplikacji, której używasz każdego dnia, albo zaktualizuj istniejący ''​spec'' ​ pod nowe wydanie jakiegoś użytecznego narzędzia, bez którego nie możesz żyć. ​+Zacznij od prostych rzeczy. Wybranie losowego pakietu i [[:​pl:​DevelopingPLD:​BasicSpecUpdate|aktualizowanie go]], może wydawać się dobrym pomysłem, ale w ten sposób prędzej sprowadzisz na siebie kłopoty. Zepsucie aplikacji, od której zależą inne pakiety, nie zaszkodzi dystrybucji samej w sobie, ale zdenerwuje ludzi i utrudni ci dalszą pracę. Spróbuj ​[[:​pl:​DevelopingPLD:​AddNewSpec|dodać plik spec]] dla małej aplikacji, której używasz każdego dnia, albo zaktualizuj istniejący ''​spec'' ​ pod nowe wydanie jakiegoś użytecznego narzędzia, bez którego nie możesz żyć. ​
  
 Zanim stwierdzisz,​ że jesteś gotowy opublikować swój ''​spec'',​ dwa razy sprawdź sekcję zależności i upewnij się, że pakiet buduje się czysto (na przykład po stworzeniu pliku RPM nie zostają żadne pliki - ''​builder''​ informuje o tym na końcu procesu). ​ Zanim stwierdzisz,​ że jesteś gotowy opublikować swój ''​spec'',​ dwa razy sprawdź sekcję zależności i upewnij się, że pakiet buduje się czysto (na przykład po stworzeniu pliku RPM nie zostają żadne pliki - ''​builder''​ informuje o tym na końcu procesu). ​
  
-Jeżeli się nudzisz i nie wiesz co mógłbyś zrobić, możesz spróbować zająć się listą [[http://​cvs.pld-linux.org/​PLD-doc/​PLD-specs-TODO?rev=HEAD|PLD-doc/​PLD-specs-TODO]] (Ta sama lista na wiki, z dodatkowymi wpisami [[http://​pld-users.org/​specs-todo|http://​pld-users.org/​specs-todo]]),​ albo generowanymi automatycznie nagłówkami TODO z *.spec: [[http://​cvs.pld-linux.org/​PLD-doc/​specs-auto-todo.txt?​rev=HEAD|PLD-doc/​specs-auto-todo.txt]] ​+Jeżeli się nudzisz i nie wiesz co mógłbyś zrobić, możesz spróbować zająć się listą [[http://​cvs.pld-linux.org/​cgi-bin/​cvsweb.cgi/​PLD-doc/​PLD-specs-TODO|PLD-doc/​PLD-specs-TODO]] (Ta sama lista na wiki, z dodatkowymi wpisami [[http://​pld-users.org/​specs-todo|http://​pld-users.org/​specs-todo]]),​ albo [[http://​cvs.pld-linux.org/​cgi-bin/​cvsweb.cgi/​PLD-doc/​PLD-update-TODO|PLD-doc/​PLD-update-TODO]]. Poza tym jest lista z generowanymi automatycznie nagłówkami TODO z *.spec: [[http://​cvs.pld-linux.org/​PLD-doc/​specs-auto-todo.txt?​rev=HEAD|PLD-doc/​specs-auto-todo.txt]]
  
  
  
 ==== Publikowanie zmian ==== ==== Publikowanie zmian ====
-Jako początkujący deweloper nie będziesz miał dostępu odczytu/​zapisu do repozytorium ​CVS, więc będziesz musiał znaleźć kogoś kto sprawdzi twoje zmiany i doda je do repozytorium. Najlepszym wyjściem jest wysłanie maila na listę ''​pld-devel-en''​ (lub ''​pl''​) i dołączenie do niego //unified diff// twoich zmian zamiast oryginalnych plików (czy wręcz całych, jeżeli jakieś dodajesz) wraz z krótkim opisem tego co zrobiłeś. ​+Jako początkujący deweloper nie będziesz miał dostępu odczytu/​zapisu do repozytorium ​git, więc będziesz musiał znaleźć kogoś kto sprawdzi twoje zmiany i doda je do repozytorium. Najlepszym wyjściem jest wysłanie maila na listę ''​pld-devel-en''​ (lub ''​pl''​) i dołączenie do niego //unified diff// twoich zmian zamiast oryginalnych plików (czy wręcz całych, jeżeli jakieś dodajesz) wraz z krótkim opisem tego co zrobiłeś. ​
  
 Jak tylko jakiś deweloper będzie miał czas przyjrzeć się twoim zmianom, zostaniesz poinformowany o ewentualnych błędach wymagających poprawek i w końcu twoje pliki zostaną opublikowane. ​ Jak tylko jakiś deweloper będzie miał czas przyjrzeć się twoim zmianom, zostaniesz poinformowany o ewentualnych błędach wymagających poprawek i w końcu twoje pliki zostaną opublikowane. ​
Line 108: Line 110:
 Kiedy twoje zmiany okażą się szczególnie cenne, inni deweloperzy mogą zdecydować się przyznać ci pełne prawa dostępu do naszego repozytorium. Ten proces jest zawsze inicjowany przez kogoś kto ma już prawa odczytu/​zapisu. Wysyłanie próśb o ten dostęp nie będzie mile widziane. ​ Kiedy twoje zmiany okażą się szczególnie cenne, inni deweloperzy mogą zdecydować się przyznać ci pełne prawa dostępu do naszego repozytorium. Ten proces jest zawsze inicjowany przez kogoś kto ma już prawa odczytu/​zapisu. Wysyłanie próśb o ten dostęp nie będzie mile widziane. ​
  
-Mając już prawa odczytu/​zapisu,​ będziesz mógł regularnie aktualizować ​CVS. Pamiętaj o sprawdzeniu plików, które dodajesz przez wysłaniem ich do repozytorium. Upewnij się także, że udostępniasz zrozumiały zapis zmian (commitlog). Zapis ten powinien mieć taki format: ​+Mając już prawa odczytu/​zapisu,​ będziesz mógł regularnie aktualizować ​repozytoria na serwerze git. Pamiętaj o sprawdzeniu plików, które dodajesz przez wysłaniem ich do repozytorium. Upewnij się także, że udostępniasz zrozumiały zapis zmian (commitlog). Zapis ten powinien mieć taki format: ​
  
  
Line 132: Line 134:
   - Od tej pory pakietem zajmuje się tylko RM. Decyduje, kiedy pakiet jest gotowy do przeniesienia do stabilnego drzewa (lub do ''​updates''​ jeśli jest to wydana wersja PLD). Jeśli sądzisz, że trwa to za długo, sprawdź czy zależności (zarówno nowo wprowadzone jak i ewentualnie popsute przez jakieś pakiety) w kolejce są spełnione. ​   - Od tej pory pakietem zajmuje się tylko RM. Decyduje, kiedy pakiet jest gotowy do przeniesienia do stabilnego drzewa (lub do ''​updates''​ jeśli jest to wydana wersja PLD). Jeśli sądzisz, że trwa to za długo, sprawdź czy zależności (zarówno nowo wprowadzone jak i ewentualnie popsute przez jakieś pakiety) w kolejce są spełnione. ​
   - W końcu pakiet jest przenoszony do stabilnej gałęzi lub do ''​updates''​ i od tej pory każdy może ten pakiet używać. ​   - W końcu pakiet jest przenoszony do stabilnej gałęzi lub do ''​updates''​ i od tej pory każdy może ten pakiet używać. ​
 +  - Pakiet trafia do ''​obsolete''​ jeśli jest przygotowana nowsza wersja pakietu. ​
  
  
pl/developingpld.1217052686.txt.gz · Last modified: 2008-07-26 08:11 by grizz