Differences

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

--- pl:developingpld:basicspecupdate [2009-09-26 03:04]
qwiat
+++ pl:developingpld:basicspecupdate [2009-09-30 23:54]
qwiat
@@ Line 1: / Line 1: @@
-====== Aktualizacja Speca ======
+====== Aktualizacja pliku spec w przykładach ======
 Zakładam, że mamy już [[: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.
+Zaczynamy od pobrania całej paczki z HEAD (ewentualnie z odpowiedniego brancha):
-===== Trywialna aktualizacja =====
-Pobieramy całą paczkę z HEAD (ewentualnie z odpowiedniego brancha):
-''$ builder -g foo''
+<file>$ builder -g foo
+</file>
+aby było nam wygodniej pracować, możemy zmienić katalog:
+<file>$ cd ~/rpm/packages/foo
+</file>
+===== Aktualizacja aplikacji w specu =====
 Teraz za pomocą edytora tekstu otwieramy plik spec:
-''$ vim ~/rpm/packages/foo/foo.spec''
+<file>$ vim ~/rpm/packages/foo/foo.spec
+</file>
 i odszukujemy sekcje odpowiedzialne za wersję, które mogą wyglądać następująco:
@@ Line 21: / Line 31: @@
 <file>Version:        1.5
 Release:        3</file>
-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.
+wartość **Version:** zmieniamy na **1.6** zaś **Release:** na **1**. Zmiana wersji wymaga, by Release ustawić na wartość 1. Wyjątkiem jest sytuacja gdy trzeba zasygnalizować, że spec nie jest skończony, wtedy nadajemy ułamkową wartość  np.: 0.1. Teraz musimy sprawdzić czy pakiet się buduje.
+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:
-===== 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''
+<file>$ builder -5 foo
+</file>
+teraz możemy budować, w poniższym przykładzie budujemy tylko binarne wersje (-bb) żeby oszczędzić na czasie.
-teraz możemy budować, w poniższym przykładzie budujemy tylko binarne wersje (-bb) żeby szczedzić na czasie.
-''$ builder -bb foo''
+<file>$ builder -bb foo
+</file>
 Jeśli pakiet się zbudował możemy wykonać commit, dodaniem odpowiedniego komentarza (-m):
-''$ cvs ci -m "- updated to 1.6" foo.spec''
-Jeśli pakiet się nie buduje to czytaj dalej
+<file>$ cvs ci -m "- updated to 1.6" foo.spec
+</file>
+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|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:
+<file>$ builder -bb foo
+</file>
+Kiedy wszystko jest w porządku możemy dokonać commit speca (i ewentualnie łatek).
@@ Line 47: / Line 79: @@
-==== 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.
+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.:
+<file>$ rm foo-special-fix.patch
+</file>
+usuwamy łatkę ze CVS-u:
+<file>$ cvs remove foo-special-fix.patch
+</file>
+i teraz możemy zrobić commit wszystkich zmian z informacją o usunięciu łatki:
+<file>$ cvs ci
+</file>
+==== Niespakietowane pliki/brak plików ====
+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.
-==== Niespakietowane pliki ====
-TODO
+==== Uwagi ====
+Warto, nawet po najmniejszej zmianie w specu, uruchomić skrypt [[:pl:DevelopingPLD:AdapterScript|adapter]], w celu weryfikacji i dokonania automatycznych poprawek:
-===== Podbicie Release =====
-TODO
+<file>$ ./adapter foo.spec
+</file>

PLD Linux Distribution

User Tools

Site Tools

Differences

Page Tools