Author: qwiat   Date: Sun Sep 27 12:10:23 2009 GMT
Module: PLDWWW   URL: 
http://pld-linux.org/pl/DevelopingPLD/BasicSpecUpdate?action=diff&rev2=3&rev1=2
---- Log message:


---- Page affected: pl/DevelopingPLD/BasicSpecUpdate

---- Diffs:

================================================================
- = Aktualizacja Speca =
+ = Aktualizacja pliku spec w przykładach =
  
  Zakładam, że mamy już [wiki:pl/DevelopingPLD/PreparingWorkingEnvironment 
przygotowane środowisko budowania], dlatego przejdziemy od razu do rzeczy. W 
przykładach będziemy aktualizować fikcyjny pakiet '''foo''' z  wersji 1.5 do 
1.6.
  
- == Trywialna aktualizacja ==
+ Zaczynamy od pobrania całej paczki z HEAD (ewentualnie z odpowiedniego 
brancha):
  
- Pobieramy całą paczkę z HEAD (ewentualnie z odpowiedniego brancha):
+ {{{
+ $ builder -g foo
+ }}}
  
- {{{$ builder -g foo}}}
+ == Aktualizacja aplikacji w specu ==
  
  Teraz za pomocą edytora tekstu otwieramy plik spec:
  
+ {{{
- {{{$ vim ~/rpm/packages/foo/foo.spec}}}
+ $ vim ~/rpm/packages/foo/foo.spec
+ }}}
  
  i odszukujemy sekcje odpowiedzialne za wersję, które mogą wyglądać 
następująco:
  
@@ -21, +25 @@

  
  wartość '''Version:''' zmieniamy na '''1.6''' zaś '''Release:''' na '''1'''. 
Zmiana wersji wymaga, by Release ustawić na wartość 1. Wyjątkiem jest sytuacja 
gdy chyba zasygnalizować, że spec nie jest skończony, wtedy nadajemy ułamkową 
wartość  np.: 0.1. Teraz musimy sprawdzić czy pakiet się buduje.
  
- 
- == Test budowania ==
- 
  Musimy sprawdzić czy pakiet się buduje zanim wykonamy commit lub wyślemy 
łatkę do jakiegoś dewelopera. Zaczniemy od aktualizacji sum md5 źródeł w 
pakiecie:
  
+ {{{
- {{{$ builder -5 foo}}}
+ $ builder -5 foo
+ }}}
  
- teraz możemy budować, w poniższym przykładzie budujemy tylko binarne wersje 
(-bb) żeby szczedzić na czasie.
+ teraz możemy budować, w poniższym przykładzie budujemy tylko binarne wersje 
(-bb) żeby oszczędzić na czasie.
  
+ {{{
- {{{$ builder -bb foo}}}
+ $ builder -bb foo
+ }}}
  
  Jeśli pakiet się zbudował możemy wykonać commit, dodaniem odpowiedniego 
komentarza (-m):
  
+ {{{
- {{{$ cvs ci -m "- updated to 1.6" foo.spec}}}
+ $ cvs ci -m "- updated to 1.6" foo.spec
+ }}}
  
- Jeśli pakiet się nie buduje to czytaj dalej
+ Jeśli pakiet się nie buduje to czytaj o Rozwiązywaniu problemów poniżej.
+ 
+ 
+ == Inne aktualizacje w specu ==
+ 
+ Każde zmiany nie dotyczące aktualizacji samej aplikacji np.:
+  * nałożenie łatek
+  * poprawienie zależności: '''Requires''' i '''BuildRequires'''
+  * modyfikacje opisów
+ wymagają podbicia tagu '''Release''', tak by pakiet mógł być zbudowany i 
zaktualizowany. Podbicia dokonuje się także wtedy, gdy żadne zmiany nie są 
robione w specu, robi się tak by aplikacja została na nowo zbudowana, np. w 
celu zlinkowania z nowszą wersją  bibliotek.
+ 
+ Po każdej zmianie, a zwłaszcza po nałożeniu łatek musimy się przekonać czy 
pakiet się buduje, zatem:
+ 
+ {{{
+ $ builder -bb foo
+ }}}
+ 
+ Kiedy wszystko jest w porządku możemy dokonać commit speca (i ewentualnie 
łatek).
  
  
  == Rozwiązywanie problemów ==
  
  Przy aktualizacji może pojawić się każdy możliwy problem jednak najczęściej 
pojawia się problem z łatami i/lub niespakietowanymi plikami.
  
- === Błąd przy nakładaniu łat ===
+ === Błąd przy nakładaniu łatek ===
  
- TODO
+ Zdarza sie, że w nowszej wersji aplikacji autorzy nałożyli już taką łatkę i 
jedyne co pozostaje nam zrobić to usunąć ją ze speca. W gorszym przypadku kod 
źródłowy zmienił się na tyle, że łatka po prostu nie da się nałożyć. Musimy 
porównać źródło z łatką i podjąć odpowiednie kroki: usunąć łatkę lub ją 
zmodyfikować, tak by się nakładała. Przy okazji można sprawdzić czy łatka w 
ogóle jest potrzebna, trzeba sprawdzić w historii rewizji po co w ogóle została 
dodana.
  
- === Niespakietowane pliki ===
+ Aby wyłączyć łatkę usuwamy ze speca odpowiedni tag '''Patch{NR}''' z nagłówka 
speca i  polecenie nakładające go z '''%prep'''. Teraz próbujemy budować (jak 
powyżej). Jeśli wszystko działa poprawnie usuwamy łatkę, w tym celu wchodzi my 
do katalogu ~/rpm/packages/foo/ i usuwamy plik o odpowiedniej nazwie np.:
  
- TODO
+ {{{
+ $ rm foo-special-fix.patch
+ }}}
+ 
+ usuwamy łatkę ze CVS-u:
+ 
+ {{{
+ $ cvs remove foo-special-fix.patch
+ }}}
+ 
+ i teraz możemy zrobić commit wszystkich zmian:
+ 
+ {{{
+ $ cvs ci
+ }}}
  
  
- == Podbicie Release ==
+ === Niespakietowane pliki/brak plików ===
  
- TODO
+ Rozwój aplikacji powoduje czasami większe lub mniejsze zmiany w liście 
plików. Builder nas poinformuje, w takim wypadku musimy dokonać zmian w 
sekcjach '''%files'''. Musimy to pamiętać by używać makr zamiast konkretnych 
ścieżek.
  
_______________________________________________
pld-cvs-commit mailing list
[email protected]
http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit

Reply via email to