Zakładam, że mamy już 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 skryptem builder całej paczki z HEAD (ewentualnie z odpowiedniego brancha):

$ builder -g foo

aby było nam wygodniej pracować, możemy zmienić katalog:

$ cd ~/rpm/packages/foo

Teraz za pomocą edytora tekstu otwieramy plik spec:

$ vim ~/rpm/packages/foo/foo.spec

i odszukujemy sekcje odpowiedzialne za wersję, które mogą wyglądać następująco:

Version:        1.5 
Release:        3

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:

$ builder -5 foo

teraz możemy budować, w poniższym przykładzie budujemy tylko binarne wersje (-bb) żeby oszczędzić na czasie.

$ 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

Jeśli pakiet się nie buduje to czytaj o Rozwiązywaniu problemów poniżej.

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

Przy aktualizacji może pojawić się każdy możliwy problem jednak najczęściej pojawia się problem z łatami i/lub niespakietowanymi plikami.

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

$ rm foo-special-fix.patch

usuwamy łatkę ze CVS-u:

$ cvs remove foo-special-fix.patch

i teraz możemy zrobić commit wszystkich zmian z informacją o usunięciu łatki:

$ cvs ci

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.

Warto, nawet po najmniejszej zmianie w specu, uruchomić skrypt adapter, w celu weryfikacji i dokonania automatycznych poprawek:

$ ./adapter foo.spec