PLD Linux Distribution

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
/* page was renamed from michaloo/DevelopingPLDpl */


====== Jak zostać deweloperem PLD ======
Ten artykuł jest próbą wyjaśnienia podstaw sposobu rozwijania dystrybucji systemów linuksowych. /* UndefinedMacro: TableOfContents(3) */ 



===== Wymagana wiedza =====
Jako że PLD jest dystrybucją bazującą na systemie paczek RPM, następująca wiedza jest niezbędna, aby kontynuować dalszą naukę: 


  * Podstawowe operacje ''rpm'' 
  * Korzystanie z systemów kontroli wersji takich jak ''git'' czy ''svn'' 
  * Obsługa różnic między plikami w oparciu o ''diff'' i ''patch'' 
  * Kompilowanie oprogramowania ze źródeł 


===== Wewnątrz PLD =====
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 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.  

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ą.  



===== Kwestie techniczne =====


==== Pliki spec ====
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''). 

Pliki ''spec'' rezydują w podkatalogach poszczególnych pakietów wewnątrz katalogu //packages// naszego [[:pl:Repositories| serwera git]]. 



==== 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]]. 



==== Ź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''. 

Ten sam skrypt jest używany przez maszyny stanowiące infrastrukturę PLD do budowania pakietów, umieszczanych później na serwerze FTP. 



==== Skrypt adaptujący ====
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 [[:pl:Repositories| repozytorium]]. 

Możesz także [[:pl:DevelopingPLD:AdapterScript|poczytać więcej o skrypcie adaptującym]]. 



==== 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 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]]. 

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. 

[[: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) ]]. 

[[http://ep09.pld-linux.org/~builderth/queue.html|Kolejka builderów PLD 3.0 (Th)]].



===== Jak się zaangażować =====


==== Lista mailingowa ====
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 repozytoriach git, CVS i SVN. 



==== Przygotowanie środowiska pracy ====
Zobacz [[:pl:DevelopingPLD:PreparingWorkingEnvironment|przygotowanie środowiska pracy]]. 



==== Praca nad pakietami ====
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). 

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 ====
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. 

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ć 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: 



<file>- pierwsza zmiana 
- druga zmiana
- trzecia zmiana
- jakieś dodatkowe informacje</file>
Nawet jeżeli w twoim commitlog jest tylko jedna wiadomość, poprzedzenie jej myślnikiem poprawi czytelność. 



==== Cykl życia pakietu ====
Po commicie pliku ''spec'', konieczne jest zbudowanie pakietu. Cały proces wygląda następująco: 


  - Plik ''spec'' jest commitowany (włączając zmiany w wymaganych łatach i innych plikach związanych z plikiem ''spec'') 
  - Jeden z deweloperów wysyła zlecenie na testowe zbudowanie pakietu (za pomocą skryptu [[http://cvs.pld-linux.org/pld-builder.new/client/make-request.sh?rev=HEAD|make-request.sh]]). Jeśli nie masz takich uprawnień, skontaktuj się w tej sprawie z RM-em. Istnieje możliwość pominięcia tego kroku i poproszenie o zbudowanie pakietu do tzw. upgrade, jednak nie jest to zalecane, gdyż upgrade pakietów na części builderów spowoduje rozsynchronizowanie oprogramowania. Na winnym takiego stanu będzie wykonana publiczna egzekucja. 
  - Pakiet jest buduje się prawidłowo na wszystkich architekturach. 
  - Jeden z uprzywilejowanych deweloperów wysyła zlecenie budowania aktualizującego (ten sam skrypt co powyżej) - skontaktuj się z RM-em w sprawie dostępu. 
  - Pakiet jest budowany ponownie i aktualizowany na wszystkich builderach. 
  - Pakiet jest zapisywany w kolejce (''ready'' dla Ac i ''test'' dla Th). 
  - 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ć. 
  - Pakiet trafia do ''obsolete'' jeśli jest przygotowana nowsza wersja pakietu. 


==== Rozwiązywanie częstych problemów ====

  * - [[:DevelopingPLD:AdvancedDeveloping:FixingAsNeeded| Fixing --as-needed problems]]