Rozwój systemu/Howto/Mandriva RPM HOWTO

Z Mandriva Poland

Tworzenie pakietów RPM - HOWTO
Strona w trakcie korekty językowej!
Trwa korekta językowa tej strony. Strona może zawierać błędy.


Spis treści


Ten dokument ma na celu pomoc ludziom, którzy chcą produkować pakiety oprogramowania, które powinny uwzględniać również dystrybucję Mandriva Linux GNU / Linux. Możesz się denerwować że, w pewien sposób pakiety różnią się nieco od pakietów napisanych na innych dystrybucjach opartych na rpm. Ten dokument powinien być przydatny dla deweloperów Mandrivy, ale także do osób zewnętrznych. Załącznik obejmujące bardziej zaawansowane tematy i jest dostępny na Development/Howto/RPM_Advanced

Dystrybucja Linux GNU / Linux jest produkowana i opublikowana przez Mandrivę Inc, z pomocą różnych autorów, testerów, tłumaczy. Niektórzy z nich są odnotowani na Distro Credits

Przedmowa

Zakłada się w tym dokumencie, że czytelnik jest "linux-ready". Zna podstawowe polecenia, strukturę katalogów, i już używa rpm, co najmniej do instalowania pakietów.

Ten dokument jest skonstruowany w taki sposób, by krok po kroku przedstawić procedury do uzyskania pakietu rpm, że również można zintegrować poprzednie źródła rpm lub źródła tar w dystrybucji Mandriva Linux GNU / Linux.

Jeśli dotąd go nie znasz, to powinieneś przeczytać jak uczestniczyć w projekcie Mandriva Cooker, który opisuje proces rozwoju systemu Mandriva Linux.

RPM z grubsza oznacza trzy rzeczy:

  • program przeznaczony do zainstalowania lub tworzenia pakietów,
  • wykorzystywany w paczkach (źródło lub binarne), utworzony przez program rpm,
  • plik o nazwie pakietu, który zawiera zarówno binarne lub źródła informacji wraz z nagłówkiem o tym, jak zainstalować/odinstalować program.

Program rpm z użytkownika punktu widzenia, jest potężnym menadżerem pakietów. Funkcjonuje on jako "przewodnik" dla wszelkich działań na pakietach rpm. Wśród innych rzeczy, może on:

  • instalować lub aktualizować pakiet sprawdzania zależności,
  • podczas instalacji pakietu wykonywać działania w celu uczynienia zainstalowany program gotowym do użycia,
  • przywracać przypadkowo skasowane pliki należące do pakietu,
  • stwierdzać, czy pakiet jest już zainstalowany,
  • znajdować pakiet, który należy do danego pliku,
  • sprawdzać instalację w celu spełnienia wymagań zależności od zainstalowanych pakietów,
  • ....

Z punktu widzenia programisty, pakującego program rpm, obejmuje on w jednym pliku rpm wszystkie informacje potrzebne do zainstalowania programu na danej platformie.

Ważne jest, by odróżniać od początku różnice między pakietami źródłowymi ( .src.rpm ) i binarnymi (.<archtype>.rpm).

Pierwszy z nich zawiera (tak trafiłeś) kompletne źródło drzewa oryginalnego programatora, plus wszystkie rzeczy dodane do pakowania w celu skonfigurowania, skompilowanie i zainstalowanie programu. Zwykle składa się z pliku specyfikacji (plik rpm powie jakie operacje są wykorzystywane w celu wykonania pakietu) wraz z poprawkami, jeśli takie istnieją.

Drugi zawiera skompilowane pliki binarne i wszystkie pliki (dokumentacja, pliki konfiguracyjne, ikony ,...), które zostaną zainstalowane w systemie docelowym. Zawiera również procedury do wprowadzenia plików na ich poprawną lokalizację, a także do wykonywania działań w celu uczynienia program obsługiwalnym.

Instalacja oprogramowania

Podstawy

Chociaż RPM został pierwotnie zaprojektowany do pracy z Red Hat Linux to także działa na innych dystrybucjach opartych na rpm: Mandriva Linux, Suse, Conectiva, etc ; rpm jest już zainstalowany w tych systemach.

Możesz pobrać rpm dystrybucji Red Hat tutaj: [1]

Binarne rpm będą opierać się systemowi Mandriva Linux, mogą nie działać we wszystkich dystrybucjach Mandriva, pozostaną zgodne z Red Hat, chociaż wszystko możliwe.

Budowanie dla Mandriva Linux

Budowania pakietów dla Cooker (czyli rozwojowej wersji systemu Mandriva Linux) jest zawsze przedmiotem małych poprawek i ulepszeń w sprawie użycia programu rpm. Otwórz dowolny serwer zwierciadlany Mandriva Cooker i otrzymasz:

  • Pakiet rpm, który jest naszą poprawką wersji Red Hat.
  • Pakiet rpm-build, który posiada skrypty wykorzystywane do budowania pakietów.
  • Pakiet spec-helper jest narzędziem do minimalizowania w specyfikacji przez robienie rzeczy takie jak automatyczne usuwanie symboli i kompresji plików binarnych na stronach man.
  • Pakiet libtool, który jest używany przez niektórych do tworzenia skonfigurowanych bibliotek współdzielonych.
  • Pakiet rpmlint, który jest wykorzystywany do sprawdzania poprawności generowanych pllików src.rpm.

Zadania wstępne

Instalacja wymaganych pakietów

Aby móc zbudować RPM, musisz mieć zainstalowany pakiet rpm-build Aby uzyskać instrukcje na temat instalowania pakietów, zobacz Instalacja i aktualizacja oprogramowania.

Tworzenie wymaganych folderów

Budowa pakietów rpm wymaga specjalnego drzewa w twoim katalogu domowym. To drzewo może zostać utworzone za pomocą następującego polecenia: mkdir -p ~/rpm/{BUILD,RPMS/$ARCH,RPMS/noarch,SOURCES,SRPMS,SPECS,tmp} . Wymień architektury $ ARCH takie jakie pakiety masz zamiar budować. Zasadniczo jest to i586, ale może być również x86_64/sparc/alpha/ppc.

UWAGA! Budowanie RPM-ów jako root jest niebezpieczne, ponieważ pliki binarne są instalowane w systemie przed zapakowaniem, więc zawsze należy budować jako zwykły użytkownik by przypadkowo nie zanieczyścić systemu.

Upewnij się, że drzewo jest w formie:

  • ~/rpm/BUILD: katalog, gdzie budowane są źródła.
  • ~/rpm/RPMS: zawiera katalogi, po jednym dla każdej architektury, które otrzymają po pakiecie binarnym.
  • ~/rpm/RPMS/i586: katalog, w którym zostaną zapisane pakiety rpm dla procesorów i586.
  • ~/rpm/RPMS/x86_64: katalog, w którym będą przechowywane pakiety rpm dla procesorów AMD64.
  • ~/rpm/RPMS/noarch: dla pakietów noarch (z procesorem independant)
  • ~/rpm/SOURCES: pliki źródłowe (np.,mypackage.tar.bz2).
  • ~/rpm/SPECS: pliki specyfikacji jakie będziemy musieli konstruować.
  • ~/rpm/SRPMS: źródło rpm po budowaniu.
  • ~/rpm/tmp: dla czasowych, jakie rpm będzie tworzyć przy budowaniu pakietów.

Uwaga: W ramach architektury katalogi ~/rpm/RPMS są niezbędne do rpm. Jeśli nie są one obecne, otrzymasz komunikat o błędzie.

Utwórz plik .rpmmacros

W celu budowania pakietów dla systemu Mandriva Linux, będziesz musiał dodać .rpmmacros plik konfiguracyjny w katalogu domowym:

%_topdir                %(echo $HOME)/rpm
%_tmppath               %(echo $HOME)/rpm/tmp

# Jeśli chcesz pakiety, które mają być automatycznie podpisane GPG, należy dodać te trzy linie
# zastępująca "Mandrivalinux" z nazwą GPG. Możesz także użyć rpm --resign
# do podpisania późniejszych pakietów.
%_signature             gpg
%_gpg_name              Mandrivalinux
%_gpg_path              ~/.gnupg

# Dodaj swoje nazwisko i adres e-mail pakującego w polu %packager. Można także 
# również zastąpić siebie jako sprzedawcę. 
%packager               John Doe <foo@mail.invalid>
%distribution           Mandriva Linux
%vendor                 Mandriva

# Jeżeli chcemy mieć pakiety do własnych distsuffix zamiast MDV, dodaj ją
# podobnie do tego
#%distsuffix             foo

Ostrzeżenie, nie należy ustawiać %optflags, jako jednego znajdującego się już u Ciebie w skali całego systemu /usr/lib/rpm/mandriva/rpmrc.

Twój program Rpm jest gotowy do budowy instalacji pakietów. Wszystkie powyższe dane mogą być wykonane w jednym strzale (dla i586), uruchamiając to instalacji skryptu RPM.

Budowanie RPM

Z istniejącego źródła RPM

Jest to zazwyczaj miejsce w przypadku pakietów, które są już zawarte w dystrybucji.

Najnowsze rpm są dostępne na wielu serwerach lustrzanych, których lista jest dostępna na zwierciadlanych serwerach Cooker. Znajdziecie je pod:

  • SRPMS źródła RPM (main, contrib jpackage, inne) oraz w ramach architektury procesora (np. i586, x86_64, ...):
  • media/main dla binarnych rpmów main.
  • media/contrib dla binarnych rpmów contrib.
  • media/jpackage dla binarnych rpmów noarch.

Po znalezieniu źródła rpm, który chcesz zmodyfikować dla systemu Mandriva Linux, problem tylko z rpm -ivh mypackage.src.rpm; następnym krokiem będzie zainstalowanie wszystkich plików źródłowych do swojego katalogu RPM. Można również pobrać źródła ustawiając urpmi.

Na przykład:

[camille@kenobi ~/rpm]$ rpm -i /cooker/SRPMS/ktron-1.0.1-2mdk.src.rpm 
[camille@kenobi ~/rpm]$ ls -R * 
SRPMS:
SPECS:
ktron.spec
SOURCES:
ktron-1.0.1.tar.bz2
RPMS:
noarch/ i686/ i586/ i386/
BUILD: 

Widzimy, że rpm ma zainstalowany w naszym drzewie źródłowym RPM plik ktron-1.0.1.tar.bz2 i plik specyfikacji (spec). Jeszcze przed budowaniem nowej wersji pakietu, to może być bardzo interesujące, aby odbudować obecny pakiet w celu zrozumienia, jeśli się go kompiluje jak to jest zestawiane. Magiczne rpmbuild to robi, poleceniem z opcją buildall:

[camille@kenobi ~/rpm]$ cd ~/rpm/SPECS
[camille@kenobi ~/rpm]$ rpmbuild -ba ktron.spec
[camille@kenobi ~/rpm]$ ls -l ~/rpm/RPMS/i586/ktron-1.0.1-2mdk.i586.rpm
[camille@kenobi ~/rpm]$ ls -l ~/rpm/SRPMS/ktron-1.0.1-2mdk.src.rpm

Jeśli budujesz zakończenie (może to ostatnie godziny na niektóre pakiety, np. jądro) bez błędów, otrzymasz do swojego binarnego ~/rpm/RPMS/i586 i ~/rpm/SRPMS/ odpowiednie podkatalogi. Jeśli chcesz zainstalować binarne rpm, musisz działać jako "root", do którego można uzyskać dostęp wpisując su (i wyjścia, wpisując control_d). Jednak w celu zbudowania rpm, aby rozwinąć jeden src.rpm, nigdy nie powinien być głównym.

Log z kompilacji może być bardzo długi i może być przechowywany do późniejszego przeglądania. Za pomocą emacs lub xemacs i użycie drugiego okna z muszli (shell Alt-x) i zapisz jako bufor ktron.LOG, np., gdy zostanie ukończony.

W katalogach ~/rpm/BUILD w których zwykle jest dostęp do poprawionych źródeł (jeśli jedna lub więcej poprawek były wydane w ~/rpm/SOURCES), do plików binarnych, skompilowanych bibliotek, manuali itp. plik specyfikacji (spec) opisuje źródło plików i poprawki, jak zbudować pakiet, jak i zainstalować pakiet.

Teraz musimy zrobić, w tym przypadku poprawę ktron, zmodyfikowanie pliku specyfikacji (spec), a następnie odbudować pakiet.

Ważne jest aby pamiętać, że każdy pakiet utrzymywany na Mandriva jest przechowywany na CVS. Pozwala to na stan pakietu, który ma być rejestrowany przez system tak, że deweloper może konsultować się z archiwum, aby sprawdzić poprzednie modyfikacje oraz, w razie konieczności powrócić do starszej wersji.

Każdy plik specyfikacji jest przechowywany na module o nazwie SPECS/<package> lub contrib-SPECS/<package>. Można uzyskać do niego dostęp na http://cvs.mandriva.com/

Szczegółowe informacje dotyczące sposobu dostępu do CVS, skonsultuj się ze stroną Mandriva Linux CVS.

Z otwartych źródeł

Na przykład, jeśli znajdziesz interesujący program na Freshmeat lub Sourceforge możesz chcieć aby były one dostępne dla wszystkich Mandriva Linux. Prawdopodobnie najlepszym sposobem na to, że jest utworzenie RPM spełniającego normy Mandrivy.

Pobierz archiwum i umieścić go w katalogu źródeł.

Wstępne kontrole

Licencja
Pomimo występowania licencji GPL, nadal istnieje szereg innych niż GPL licencji wykorzystywanych na dzień dzisiejszy. Sprawdź licencję oprogramowania, aby dokładnie określić, czy mogą zostać włączone do dystrybucji. Nie przyjmujemy bez otwartego oprogramowania ale istnieją pewne wyjątki dla klubu. Również nie możemy przyjąć, że oprogramowanie nie pozwala nam go swobodnie rozpowszechniać. Uważaj na te programy. Lista licencji i akceptowanego oprogramowania można znaleźć na licencje Mandrivy
Kompresja archiwum
W celu zatrzymania na przyszłość naszych wysiłków, zaleca się korzystanie z oryginalnego archiwum, bez żadnych modyfikacji. Jeśli źródła są dostępne w różnych metodach kompresji, często wybiera się .tar.bz2. Unikaj formatu kompresji tekstu (tak jak produkowane przez diff) i innych konfiguracji /skrypty/etc. przy trudniejszych (tekstowych) plikach, zwykle zapisuje niewiele miejsca, aby zobaczyć zmiany w Subversion diffu (Subversion, także korzysta już z jakieś formy kompresji). Uwaga: W przypadku wysokiego ryzyka zabezpieczeń krytycznych pakietów zalecamy nie modyfikować oryginalnego źródła dystrybucji, wpłynie to na zmianę sumy kontrolnej/podpis. Dla tych rodzajów paczek zalecamy pozostawienie ich w oryginalnej formie, tak że gdy ktoś działa na md5sum/gpg będzie odpowiadał za lokalizację pobierania wymienionych wartości. Jedynym przykładem, gdzie wyjątek ten może mieć zastosowanie jest OpenSSH.

Wewnątrz pliku specyfikacji

Jest to ważny punkt tego dokumentu. Plik specyfikacji (plik spec) zawiera wszystkie informacje wymagane przez rpm do:

  1. skompilowania programu i budowania źródła i binarnego RPM,
  2. zainstalowania i odinstalowania programu na komputerze użytkownika końcowego.

Fakt, te dwa typy informacji są połączone w jeden plik, może być bardzo mylące dla początkujących. Właściwie, to ze względu na źródło drzewa tar , które zawiera już te informacje. Procedura instalacji jest jako pochodną z ogólnego procesu instalacji w drzewie źródłowym prowadzonym przez make install, obie części są ściśle ze sobą powiązane.

W skrócie, plik spec opisuje "symulację" kompilacji i instalacji, które mówi rpm jak pliki wynikające z tej instalacji mają być pakowane i jak mają zostać ostatecznie zainstalowane w systemie użytkownika. Polecenia są wykonywane przy użyciu powłoki /bin/sh , takie rzeczy jak [ -f configure.in ] && autoconf są ważne.

Ta część nie jest przeznaczona do szczegółowego wyjaśnienia wszystkich funkcji w pliku specyfikacji. Książka Maximum RPM (patrz punkt 7) wyjaśnia to dogłębnie. Wszystko co będziemy tutaj robić to jest szybkie sprawdzenie wszystkich funkcji używanych w jednym standardowym przykładzie pliku spec Mandriva.

Jest to kuchenny przykład z repozytorium. Można również rozważyć nasz szablon plików spec aby rozpocząć jeden od podstaw.

Ponieważ można budować coraz większy RPM, można zauważyć że istnieją pewne opcje, o których Wam nie powiedzieliśmy. RPM jest bardzo rozszerzalny, więc znalezienie ich wszystkich pozostawiamy jako ćwiczenie dla czytelnika. Jest zawsze dobrą praktyką, aby otworzyć niektóre pliki spec do zapoznania się nimi i zobaczyć jak one działają.

Tutaj można uzyskać listę poprawek i specyfikacji.

%define name    gif2png - zdefiniowana nazwa gif2png
%define version 2.0.1  -  zdefiniowana wersja 2.0.1
%define release %mkrel 1  -  zdefiniowane wydania 

Name:           %{name} 
Summary:        Tools for converting websites from using GIFs to using PNGs (Narzędzia do konwertowania stron internetowych 
z wykorzystaniem obrazów GIF do korzystania z PNG)
Version:        %{version} 
Release:        %{release} 
Source0:        http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2 
Source1:        %{name}-%{version}-mdk-addon.tar.bz2 
Patch0:         gif2png-2.0.1-bugfix.patch.bz2 
URL:            http://www.tuxedo.org/~esr/gif2png/ 

Group:          Applications/Multimedia 
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-buildroot 
License:        MIT-like 
Requires:       python 

%description
Narzędzia do konwersji obrazów GIF do PNG. program konwertuje pliki GIF 
do plików PNG. Python web2png konwertuje całe drzewa internetowe, również 
łata strony HTML, aby odniesienia img src były poprawne. 

%prep 
%setup -q -a 1 
%patch -p1 

%build 
%configure 
%make

%install
rm -rf $RPM_BUILD_ROOT
%makeinstall

%clean 
rm -rf $RPM_BUILD_ROOT 

%files 
%defattr(0755,root,root) 
%doc README NEWS COPYING AUTHORS 
%{_mandir}/man1/gif2png.1*
%{_mandir}/man1/web2png.1*
%{_bindir}/gif2png 
%{_bindir}/web2png 

%changelog 
* Mon Nov 02 1999 Camille Begnis <camille@mandrakesoft.com> 2.0.1-1mdk
- Upgraded to 2.0.1 

* Mon Oct 25 1999 Camille Begnis <camille@mandrakesoft.com> 2.0.0-1mdk
- dostosowanie specyfikacji dla Mandrake 
- dodanie wymogu python 
- kompresja Gz do bz2

Następnie zanalizuj szczegółowo każdą linię tego pliku:

Bądź ostrożny, % na początku wiersza może nakazać różne rzeczy:

  • początek sekcji (prep, kompilacja, instalacja, czyste)
  • wbudowany skrypt makro (konfiguracja, poprawki)
  • dyrektywy wykorzystywane przez specjalną sekcję (defattr, doc, ...)

Nagłówek sekcji

%define name    gif2png
%define version 2.0.1
%define release %mkrel 1

Te trzy linie definiują stałe, które mogą być wykorzystywane w wielu następnych sekcjach pliku spec o nazwie %{name} , %{version} i %{release} .Jest makro Mandriva %mkrel, które powinno być wykorzystane aby dodać MDV po wydaniu, numer można znaleźć Distro Specific Release Tag.

Następnie możemy wypełnić kilka pól informacyjnych dla rpm:

Name:           %{name}

Nazwa pakietu i sposób wykorzystywania imienia pakietu oraz pakiet bazy danych na komputerze użytkownika.

Zauważ, że "%{name} " jest odniesieniem do poprzedniej definicji.

Version:        %{version}
Release:        %{release}

W tym momencie musimy wyjaśnić, jaka jest nazwa utworzonego pakietu. Ważne jest, aby zawsze względem tego standardu, tak aby twoja praca była zrozumiała dla innych.

Istnieją również pewne znaczniki, których nie ma w przykładowym pliku spec ale możesz chcieć wiedzieć. Nie spodziewamy się, że to wszystko zapamiętasz jeśli rozpocząłeś budowę RPM, ale po pewnym czasie ta lista uczyni dobre referencje!

  • Pakiet binarny o nazwie: name-version-release.arch.rpm
  • Pakiet source o nazwie: name-version-release.src.rpm (tj. gif2png-2.0.1-1mdk.src.rpm w naszym przykładzie)

Nazwisko jest na ogół wybierane do nazwy z głównego pakietu binarnego, choć z odpowiedniego powodu można uniknąć kary za inną nazwę.

Wersja jest od liczby rozpakowanego źródła. Jest to numer wersji w nazwie oryginalnego pliku archiwum: nazwa-wersja.tar.gz.

Wydanie to liczba po MDV (skrót od "Mandriva"; jest absolutnie obowiązkowe), które jest zwiększane przy każdej nowej kompilacji pakietu. Może to być ze względu na zastosowane poprawki do źródeł, do zmiany pliku spec, dodanie ikony, itp.

Podsumowanie: narzędzia do konwersji z wykorzystaniem stron internetowych przy użyciu obrazów GIF do PNG

Ta linia jest jedną z linii z opisu pakietu.

Source0:        http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2 

Powyższa linia mówi rpm co plik źródłowy wykorzystuje do budowy tego pakietu. Zauważ, że nazwa pliku jest poprzedzona pełnym adresem URL (co jest fakultatywne) wskazując miejsce, gdzie pierwotne źródło jest dostępne; rpm usunie url, zachowaj tylko nazwę pliku i wyszukaj w katalogu SOURCES. Chociaż mówimy, że pełny adres URL nie jest obowiązkowy, jest wysoce zalecane by ludzie wiedzieli, gdzie szukać nowych źródeł, oni lubią podejmować się modernizacji źródła i wykonywać rekompilację. Pozwoli to narzędziu, takie jak rpmbuildupdate automatycznie przebudować nowe wersje (zobacz rpmbuildupdate aby uzyskać więcej informacji).

Gdy istnieje więcej niż jeden plik źródłowy, należy skorzystać z innych linii Source1: ..., a następnie Source2: ..., itp.

Patch0:         gif2png-2.0.1-bugfix.patch.bz2

Dwa powody, opcjonalne dla tego tagu:

  1. Któremu naprawiłeś błąd w programie źródłowym. Wygenerowałeś plik poprawki, który ma być stosowany w źródłach przed kompilacją. Zauważ, że wszystkie poprawki są skompresowane jako bzip2 nawet gdy jest mała poprawka nie może korzystać z kompresji bzip2, ale musi być spójna z bzip.
  2. Zostałeś ostrzeżony o istnieniu poprawki dla swojego oprogramowania w wersji gdzieś w sieci i pobrałeś go.

Zauważ, że plik poprawki musi być umieszczony w katalogu SOURCES jeśli chodzi o źródła może być kilka łat, będą nazwane Patch1, Patch2, itp.

URL:            http://www.tuxedo.org/~esr/gif2png/

Ta linia (opcjonalna, ale bardzo zalecana) wskazuje na stronę główną programu.

Group:          Multimedia

Mówi to rpm, w której części ogólnego pakietu drzewa umieścić ten pakiet. Ta funkcja jest używana w pakiecie końcowych front-menedżerów, takie jak rpmdrake lub kpackage.

Kompletną strukturę grupy, do wykorzystania, która jest różna od tej którą używa Red Hat, można znaleźć na stronie grupy RPM. Jest to obowiązkowe, inaczej Twój pakiet wprowadzi bałagan z innymi paczkami wyboru drzewa instalatora Mandriva Linux lub w menedżerze pakietów przód - koniec.

BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-buildroot

Ta linia jest bardzo ważna i nie może zostać pominięta. Rpm mówi, że do zainstalowania programu będzie musiał użyć specjalnego katalogu głównego (a fake "/") na skompletowanie komputera. Istnieją dwa powody:

  1. Gdy budujesz rpm, nie masz dostępu do administratora komputera, więc nie można zainstalować pakietu w normalnych katalogach.
  2. Instalacja do roboczego drzewa, roboczej maszyny prawdopodobnie zmyli pliki z pakietami innych plików, najważniejsze, może to być niebezpieczne jeśli pakiet jest już zainstalowany. Wielu ludzi używa /var/tmp lub /tmp na buildroot. Nie musi to stanowić problemu, jeśli jesteś jedynym użytkownikiem swojego komputera, ale jeśli masz wielu użytkowników na komputerze, a oni kompilują ten sam pakiet w tym samym czasie będzie barf rpm. Dlatego ważne jest, aby określić %{_tmppath} w obrębie własnego katalogu domowego!
License:        MIT-like

Ten tag (zastępując prawa autorskie) definiuje licencje wybrane przez posiadacza praw autorskich, które będą miały zastosowanie do pakowania oprogramowania. W większości przypadków jest ona zgodna z GPL. Zobacz pełną listę ważnych licencji na licencje Mandrivy i Polityki Licencyjnej

Requires:       python

Ta linia została dodana, ponieważ jeden z programów zawartych w pakiecie to skrypt Pythona. Python musi być wykonalny. Możesz umieścić opcjonalne minimum (lub równowartość) wersji, na przykład: Wymaga: python> = 1.5.1

%description
Narzędzia do konwersji obrazów GIF do PNG. Program Gif2png konwertuje pliki GIF 
do plików PNG. Skrypt w języku Python web2png konwertuje całe drzewa internetowe, 
również łatanie stron HTML, aby odniesienia img src były poprawne.

Jest to całkiem specjalną etykietą wewnątrz nagłówka pliku spec, ponieważ jest to pełny tekst składa się, w razie potrzeby z różnych linii i akapitów. Zawiera pełny opis oprogramowania instalowanego by pomóc użytkownikowi zdecydować, czy chce zainstalować pakiet lub nie.

W tym momencie możesz siebie zapytać: "A co z tłumaczeniami?" Faktycznie, w celu poprawy czytelności plików spec, tagi streszczenia i tłumaczenia opisu są przechowywane w specjalnym pliku o nazwie <package>.po.

Pliki te są przechowywane w module poSPECS Cooker w cvs. Kiedy tworzony jest nowy pakiet, podstawowy plik PO zostanie automatycznie utworzony w tym module dla przyszłych tłumaczeń.

Ta metoda zakłada, że cały tekst wewnątrz pliku spec jest napisany w języku angielskim. Z wyjątkiem jednak, pakiety przeznaczone dla danego języka (np., ispell-de). W takim przypadku zaleca się tekst w dwóch językach: angielskim oraz w języku danego pakietu. Będziesz używać specjalnych tagów dla tego: Summary(de): .. i %description -l de.

Sekcja Prep

%prep  
%setup -q -a 1
%patch0 -p1

W tej sekcji jest napisany pierwszy skrypt wykonywany przez rpm. Jego zadaniem jest:

  • utworzenie najwyższego poziomu budowanego katalogu (w build),
  • rozpakowanie oryginalnego źródła do budowania katalogu,
  • zastosowanie opcjonalnej łatki w źródle.

Mogą one być potem poprzedzone przez wszystkie komendy w pakerze chcąc uzyskać gotowe źródła do budowania.

%setup -q -a 1 

Jest to pusty skrypt makro, w którym

  • cd do budowania drzewa,
  • wyodrębnia źródła (w trybie cichym,-q)
  • zmienia własność i uprawnienia plików źródłowych.

Domyślnie wyciąga to pierwsze źródła; musisz użyć parametrów dla jakichkolwiek innych źródeł, w naszym przykładzie -a 1 mówimy, że chcemy również wydobyć ze źródeł numer 1.

Istnieją inne ciekawe przełączniki, które mogą być używane z makra %setup:

  • -c name - przełącznik-c napisze, że górny katalog tworzony jest jako pierwszy, potem CD w tym katalogu, a następnie rozpakuj Source0. Jest to przydatne, gdy niektóre pakiety są nieodpowiednie (sens?; DickGevers) tar.bz-ipped bez katalogu nadrzędnego.
  • -D - nie usuwa katalogu przed rozpakowywaniem. Przydaje się tylko, jeśli masz więcej niż jedno makro instalacyjne. Powinien być używany wyłącznie w konfiguracji makr po pierwszej (ale nie w pierwszej).
  • -T - opcja ta zastępuje domyślne działanie Dekompresji Source i wymaga-b 0 lub-a 0 by dostać główny niespakowany plik źródła. Potrzebujesz tego przy istniejących źródłach wtórnych.
  • -n name - jeśli nazwa rpm jest inna niż ta co źródło rozpakowuje, użyj tego przełącznika. Dla przykładu: jeżeli nazwa jest program rpm-wersja-rewizja i rozpakowuje źródło tar do programu-wersja-data, w procesie budowania rpm nie będzie w stanie wejść w katalogu -wersji programu, więc należy użyć programu-n-wersji daty, więc rpm pozna nowy katalog, w którym proces będzie kontynuować.
%patch0 -p1

Makro odpowiedzialne za stosowanie poprawki do źródeł; jej parametr "-p<num>" jest przekazywany do poprawki programu. Wyobraź sobie, jeśli miałeś inne poprawki zgłoszone Patch1: .. w nagłówku sekcji, należy dodać kolejną linię %patch1 -p1. Dodanie -b .twój_przydomek byłoby również miłym, jak możesz niech inni się dowiedzą co robią twoje poprawki lub kto zrobił poprawki. Np., jeśli Fred zrobił poprawkę, wtedy mógłby zrobić %patch -p1 -b .fred, albo Barney zrobił jej poprawki mogłby być %patch -p1 -b .barney

Sekcja budowy

%build 

Ta sekcja będzie zawierać skrypt odpowiedzialny za faktyczną kompilację oprogramowania.

Składa się on z polecenia wydawanego podczas budowania pakietów z rozpakowanego drzewa źródła tar.

%configure

Ta linia jest używana do konfigurowania źródeł autoconf'ed. %configure wydaje ./configure z wieloma dodatkami takimi jak

export CFLAGS="$RPM_OPT_FLAGS"

przed skonfigurowaniem, opcje takie jak

i586-mandrake-linux --prefix=/usr --datadir=/usr/share
itp.

Czasami te argumenty nie są obsługiwane przez skrypt configure. W takim przypadku, musisz odkryć przyczynę, i wydaj ./configure z odpowiednimi parametrami. Daj docelową platformę do konfiguracji połączenia, jeśli jest oczywiście obsługiwana z %{targetplatform} ; specyfikacji architektury należy unikać w pliku spec; na ix86 to powiększy się do i586-mandrake-linux, jak pokazano w powyższym przykładzie.

Należy pamiętać, że do korzystania z pakietu libtool potrzebne są pakiety %configure z budowanych współdzielonych bibliotek.

Przy budowaniu i podczas badania swojego pakietu należy sprawdzić, czy docelowy host jest właściwy z i586; w szczególności, przy kompilacji na wyższy typ procesora, domyślne zachowanie skryptu configure jest do odkrycia naszego procesora oraz jego optymalizacji. Celem makra %configure jest uniknięcie takiego zachowania.

%make

Jest to proste makro, które wykonuje się w zasadzie z odpowiednim patametrem wieloprocesorowym -j<num>.

Dla źródeł wykorzystujących xmkmf, należy wymienić następne wykonanie z:

make CDEBUGFLAGS="$RPM_OPT_FLAGS" CXXDEBUGFLAGS="$RPM_OPT_FLAGS" 

Dla innych pakietów, w wielu (ale nie wszystkich) przypadkach będzie to proste.

Sekcja instalacji

%install 

Ta sekcja będzie zawierać skrypt odpowiedzialny za faktyczne zainstalowanie pakietu symulacji instalacji w dir.: $RPM_BUILD_ROOT.

Będzie on zawierał wszystkie niezbędne komendy do uruchomienia gotowego oprogramowania w systemie użytkownika.

rm -rf $RPM_BUILD_ROOT

Jest to pierwsze polecenie wykonywane w sekcji %install ale sprząta ewentualne wcześniejszy katalog instalacyjny.

%makeinstall

Ta linia ostatecznie instaluje oprogramowanie do katalogu symulacji instalacji źródeł autoconf'ed. To makro powiększy się o wiele opcji "make install" aby zainstalować w katalogu symulacji $RPM_BUILD_ROOT, np.

prefix=$RPM_BUILD_ROOT%{_prefix} bindir=$RPM_BUILD_ROOT%{_bindir}

itp.

W niektórych przypadkach skrypt configure będzie częściowo uszkodzony i być może trzeba poszukać w Makefile dodatkowych parametrów, aby zainstalować go poprawnie. Jednym z najczęściej spotykanych jest użycie make install DESTDIR = $ RPM_BUILD_ROOT.

Aby zaoszczędzić miejsce na dysku, jak i czas pobierania Mandriva używa do kompresji bzip2-man oraz info-stron. Jednakże, ten aspekt jest obsługiwany bezpośrednio przez Mandriva przy niestandardowym programie rpm. W tym momencie w pliku spec, starszych pakietów zawarte są niektóre linie takie jak $RPM_BUILD_ROOT%{_mandir} -type f -exec bzip2 -9f {} \;

To jest taka sama dla starych taśm $RPM_BUILD_ROOT%{_bindir}/* || : lines: muszą zostać usunięte

Wszystkie te rzeczy mają przygotować pliki, które mają być gotowe do pakowania.

%clean

Ta sekcja jest przeznaczona do czyszczenia budowanego drzewa katalogów, $RPM_BUILD_ROOT.

rm -rf $RPM_BUILD_ROOT

Tak jest, gdy praca jest wykonywana.

Sekcja plików

%files 

Ta sekcja składa się z listy plików, które będą zbierane z naszej symulacji katalogów, które mają być pakowane w paczki. Zobacz porządny podręcznik dla różnych opcji, użytych w tym prostym przykładzie.

Listy plików musi być napisana ręcznie w pliku spec. Może on być skonstruowany przez sporządzenie listy wszystkich plików tworzonych przez rpm w budowie drzewa katalogów. Aby to zrobić, wydaj rpmbuild -bi mypackage.spec w celu powstrzymania procesu budowania po prostu zainstalowanie symulacji. Następnie, poszukaj w symulacjach instalacji katalogu, w naszym przypadku ~/rpm/tmp/gif2png-buildroot aby zobaczyć pliki, które chcesz umieścić w swoim pakiecie (przez większość czasu, można umieścić je wszystkie).

Należy pamiętać, że nigdy nie powinno się używać, do włączenia budowania znalezionej listy plików, ale wyraźnie listę wszystkich plików (będą pojawiać się błędy w nowych wersjach). Jedynymi wyjątkami są pliki lokalizacji, dla których należy użyć %find_lang %{name} w sekcji %install i zastąpić %files na %files -f %{name}.lang (zobacz dodatek B).

Uwaga na temat struktury katalogów: pliki instalowane przez pakiet "powinny" pójść za poleceniami FHS http://www.pathname.com/fhs

%defattr(0755,root,root)

Ten tag określa atrybuty, które mają być stosowane do każdego pliku skopiowanego do systemu użytkownika. Wydane cztery argumenty oznaczają:

  • -: wszystkie atrybuty dla zwykłych plików są niezmienne,
  • root: właścicielem pliku jest root,
  • root: grupą pliku jest root,
  • 0755: atrybuty stosowane do wszystkich katalogów posiadanych przez ten pakiet to 0755 ( rwxr-xr-x ).
%doc README NEWS COPYING AUTHORS

Specjalnym znacznikiem (tag) %doc wyznacza się pliki z częścią dokumentacji pakietu. Wspomniane pliki zostaną umieszczone w /usr/share/doc/gif2png-2.0.1/. Ten katalog zostanie automatycznie utworzony. Pliki określone przez %doc są w stosunku do rozpakowanego tar swojego źródła w katalogu BUILD.

%{_mandir}/man1/gif2png.1*
%{_mandir}/man1/web2png.1*

Zaleca się tutaj również listę każdego człowieka lub oddzielnie pliku info.

Również możesz się zastanawiać dlaczego gif2png.1 * był używany zamiast gif2png.1.bz2. Odbywa się to w celu zachowania kompatybilności z innymi systemami, które mogłyby użyć kompresji gzip zamiast Mandriva bzip. Jeśli znajdziesz takie referencje bz2 do kompresji plików w specyfikacji, zmień je na symbol wieloznaczny. W większości można nawet użyć %{_mandir}/man1/*, będzie to mogło znaleźć wszystkie pliki.

%{_bindir}/gif2png
%{_bindir}/web2png

Jak widać, maszych makr potrzebujesz dla każdego rodzaju ścieżki. Tutaj są najbardziej przydatne z nich (zobacz na plik /usr/lib/rpm/macros dla wszystkich): %{_prefix} , %{_bindir} , %{_sbindir} , %{_datadir} , %{_libdir} , %{_sysconfdir} , %{_mandir} , %{_infodir} . Do gry, skorzystaj z %{_gamesbindir} i %{_gamesdatadir} .

Sekcja changelog

%changelog 

Ta sekcja śledzi różne zmiany dokonane w pakiecie. Każde nowe wydanie pakietu kompilacji musi odpowiadać akapitowi niniejszej sekcji, jak również wzrost numeru wydania (jeśli nie jest w numerze wersji). Struktura tych ustępów musi być przestrzegana w następujący sposób:

* Mon Nov 02 1999 Camille Begnis <camille@mandrakesoft.com> 2.0.1-1mdk 
  • Pierwszy wiersz akapitu zaczyna się od *, w kolejności każdy oddzielony spacją:
  • trzy litery dnia tygodnia,
  • trzy litery miesiąca,
  • dwie cyfry dnia miesiąca,
  • cztery cyfry oznaczające rok,
  • imię pakującego,
  • nazwisko pakującego,
  • e-mail do pakera między <>,
  • wersja wydania i aktualny modifs.
- Upgraded to 2.0.1

Wtedy następuje zmiana jednej linijki modyfikacji,odnosi się do pakietu zaczynającego z -.

Przykłady:

- plik specyfikacji wykradziony z korganizer.  
- ostatnie migawki przed wydaniem 
- adaptacja Mandrivy. 
- popraw błąd w pliku /etc/zsh używaj USERNAME zamiast USER.
- usuń drobiazgi, które drażnią innych graczy.  
- popraw /etc/* plików źródłowych z katalogu /etc/profile.d/ 
- popraw błędy w katalogu przykładów
- naprawione wymagania wersji wyzwolenia QT
- dodaj poprawkę do obsługi Earl Gray 

Należy pamiętać, że domyślnie tylko wpisy młodsze niż 1 rok zostaną zachowane w zbudowanym pakiecie. Aby zmienić to zachowanie zmodyfikuj wartość %_changelog_truncate

Budowanie

Nasz plik specyfikacji jest ostatecznie zakończony. Weź długi oddech, usiądź i napisz rpmbuild -ba mypackage.spec

Możesz także dodać opcję --clean, która czyści pakiety BUILD po zakończeniu budowy. Jest to przydatne, jeśli masz mało miejsca na dysku.

Istnieją dwie możliwości dla Twojej ostatniej linii procesu:

  • 0.01% probabilities: + exit 0 (0.01% prawdopodobieństwa: + exit 0)
  • 99.99% probabilities for other cases. (99,99% prawdopodobieństwa dla innych przypadków)

Jesteś w drugim przypadku? Gratulujemy przeszedłeś test, nie jesteś obcy.

Powodzenia na przyszłość, zajrzyj do opcji budowania rpm (man rpmbuild ) by debugować swoją pracę, spójrz na skrypty innych osób, itp...

Jest bardzo jasny sposób budowania pakietów: wykorzystaj rpmbuild -bs --rmspec --rmsource (by usunąć cokolwiek z oryginalnego budulca), a następnie odbuduj rpmbuild --rebuild.

Optymalizacja kompilacji

Po uruchomieniu polecenia do zbudowania Twojego pakietu, z pewnością zauważyłeś taki komunikat "foo-devel is necessary for foo2".

Oznacza to, że potrzebuje informacji z innych pakietów używanych do rozwoju (zazwyczaj pliki o nazwie foo.h). Jeśli nie masz ich, kompilacja zatrzyma się lub funkcji będzie brakować w Twoim pakiecie.

W miejscu, gdzie wszystkie oficjalne pakiety są budowane (budownie klastrów w Mandriva) mają wiele preinstalowanych pakietów devel. Jeśli jeden nie jest zadeklarowany w pliku specyfikacji i jest obowiązkowy, pakiet zostanie zbudowany i tak na tym klastrze. To zadziała, ale brak tej informacji uniemożliwia budowę, rozwój pakietu na maszynach, będzie trudniejsze debugowanie/modernizacja.

Spójrz na strone internetową pakietu, tam uzyskasz informacje na temat potrzebnych składników (ale nie zawsze)

Pomyśl czy dopaść te "brakujące BuildRequires", czy rozpocząć pakowanie tylko podstaw rozwijane pakiety:

  • glibc-devel
  • libncurses5-devel
  • libstdc++6-devel

Następnie zainstaluj tylko pakiet względny rozwojowy pakiet, który jest wyznaczony przez rpm do budowy polecenia.

Kiedy rozpocznie budowę, należy uważać na "sprawdzanie .." wiadomości.

Jeśli widzisz coś podobnego do "kontroli na foo... foo.h nie found", oznacza to, że potrzebny nagłówek nie został znaleziony w systemie. Wyszukaj rozwojowy pakiet zawierający "foo.h", ale należy zachować ostrożność: możesz znaleźć więcej niż jeden pakiet zawierający to czego szukasz. Więc wybierz bardziej oczywisty pakiet. Nie należy wybrać sieci powiązanych pakietów podczas budowania solidnych aplikacji (na przykład).

Następnie zainstaluj go w systemie, a nie zapomnij dodać swojego nazwiska w sekcji BuildRequires Twojego pliku SPEC.

Brakujących nagłówków można również znaleźć podczas samej kompilacji. Jeśli się zatrzyma, sprawdź na inne brakujące "foo.h" i stosuj te same receptury.

Testowanie RPM

Należy również sprawdzić strony Bugzilli czy udzielono informacji na ten temat.

Podstawowe testy

Pierwsze kroki do wykonania to:

  • czy RPM tworzone są w odpowiednich katalogach z poprawnymi nazwami? (w ~/rpm/SRPMS/ i ~/rpm/RPMS/i586/)
  • Czy informacje uzyskane od wydania polecenia rpm -qlivp --changelog mypackage.(src.)rpm są poprawne?

Pakiet Linting

Następnie, musisz użyć rpmlint, który będzie testować różne rzeczy w paczce. Typ rpmlint mypackage.<archtype>.rpm oraz sprawozdanie z określonego pakietu zostaną wydane. Dla większej precyzji, należy użyć -i. Należy sprawdzić rpm i src.rpm. Więcej informacji na temat błędów można znaleźć na Problemy paczek

Test instalacji

Na dowolnej maszynie - ale najlepiej na innej niż używanej do kompilacji - zrób uaktualnienie lub zainstaluj a następnie sprawdź:

  • Czy wszystkie oczekiwane pliki są utworzone w ich oczekiwanych miejscach z oczekiwanymi prawami i właścicielami?
  • Czy wszystkie modyfikacje instalacji (jeśli występują) są skuteczne?
  • Czy wszystkie pliki binarne są wykonywalne, a dokumentacja przeznaczona dla użytkowników jest dostępna?

Perfekcjoniści powinni spróbować różnych instalacji i odinstalowania programu aby sprawdzić, czy wszystkie oczekiwane funkcje są realizowane prawidłowo, np. bez wymaganych pakietów.

Jeśli wszystkie testy przeszły pomyślnie to są poprawie zrobione i powinny przejść do ostatniego etapu procesu: składanie pakietów.

Coś się stało?

Cóż, wydaje się, że czytasz ten dokument, który jest dobrym początkiem. Jeśli nie udało się znaleźć tutaj odpowiedzi na swoje pytanie powinieneś spróbować w podanej kolejności:

Ogólne o sprawach RPM:

  1. Oficjalny RPM-HOWTO (zainstalowany Twoim systemie wraz z programem rpm).
  2. Książka od Red Hat "Maximum RPM", która jest dostępna na http://www.redhat.com/docs/books/max-rpm/max-rpm-html/.
  3. Poczta, pytanie na liście mailingowej rpm-list subskrybowanych przez Ciebie podczas czytania tej strony howto.

Określenie Mandriva RPM ma znaczenie:

Kliknij linię do Mandriva's Quality Assurance, <tomasz.bednarski@mandriva.pl>.

Jeśli uważasz, że znalazłeś informacje mogące być użytecznymi dla innych i wejść w zakres tego dokumentu, zachęcamy do przedstawienia swojej propozycji do opiekuna tego dokumentu.

Przed i po instalacji skryptów

Podstawy

Pakiet RPM jest w rzeczywistości trochę więcej niż zwykłym archiwum zawierającym pliki, które mają być rozszerzone w poszczególnych katalogach w systemie hosta klienta.

System oferuje dla programisty wielką cechą: przed i po instalacji skryptów. Pozwala ona paczce na napisanie kawałka kodu, który zostanie wykonany na komputerze klienta podczas instalacji lub usuwania pakietów.

Skrypty te są wykonane z sh ważnych wszelkich poleceń. Istnieją cztery z nich:

Istnieją pewne zastrzeżenia dotyczące tych skryptów, które należy wziąć pod uwagę. Numer jeden, każdy musi mieścić się w obrębie bufor 8192, a numer dwa, powinny one być nie-interaktywne. Cokolwiek wymaga ręcznego wprowadzania danych przez użytkownika jest złe, to rozbije instalację interaktywnych procedur RPM.

  • %pre - Ten skrypt jest wykonywany tuż przed pakietem instalowanym w systemie.
  • %post - Ten skrypt jest wykonywany po prostu pakiet jest zainstalowany w systemie.
  • %preun - Ten skrypt jest wykonywany zanim pakiet po prostu się odinstaluje z systemu.
  • %postun - Ten skrypt jest wykonywany tuż po odinstalowaniu pakietu z systemu.

Zakresy tych skryptów mogą być bardzo duże, i muszą być zaprojektowane z wielką ostrożnością, aby nie zaszkodzić systemowi hosta. Należy pamiętać, że te skrypty będą uruchamiane jako root ... Odpowiadają one zadaniom administratora systemu, musiałyby osiągnąć podczas instalacji programu na nowy system. Na przykład:

  • Dodaj pracę cron uruchomiony program w stałych odstępach czasu
  • Uruchom chkconfig aby uruchomić demona w czasie rozruchu
  • ...

Postępowanie z uaktualnieniami

Fakt, że pakiet może być zmodernizowany, a nie po prostu zainstalowany lub usunięty, sprawia że rzeczy trochę trudniejsze ... Problem polega na tym, że skrypt %postun z aktualizacji jest uruchamiany po %post w starej wersji. Więc %post wszystkich rzeczy jest utracony ...

Często się przydaje do zapewnienia, że działanie występuje tylko podczas instalacji, a nie w trakcie aktualizacji. Podobnie do działania, że występuje tylko podczas odinstalowywania, a nie w trakcie aktualizacji. RPM jest mechanizmem radzenia do zajmowania się tym argumentem, który jest przekazywany wstępnie do domyślnych skryptów %pre, %preun, %post i %postun.

Argument ten wskazuje liczbę wystąpień tego RPM, które zostaną zainstalowane na komputerze, gdy aktualny skrypt zostanie zakończony. Na przykład, jeśli nowy pakiet jest instalowany wtedy 1 będzie przekazywany do wstępnego %pre i 1 przekazany do %post. Kiedy pakiet zostanie zaktualizowany, 2 zostanie przekazany do %pre nowego RPM, 2, będą przekazywane do %post nowego RPM, 1 zostaną przekazane do %preun starszego RPM i 1 zostaną przekazane do %postun starego pakietu.

Tabela A-1. Wartość parametru przekazywana do skryptów przed i po
Parameter \ Script  %pre  %post  %preun  %postun
za pierwszym razem zainstaluje 1 1 N/C N/C
dla uaktualnienia 2 2 1 1
dla usunięcia N/C N/C 0 0

Pozwoli to na programator do rozróżnienia różnych postaw swoich skryptów w zależności od operacji: zainstalować lub uaktualnić.

  • Do zainstalowania skryptu ( %post, %pre ) sprawdzi, czy $ 1 jest równa "1" wtedy po raz pierwszy zainstaluje a nie aktualizacji.
  • Do odinstalowania skryptu ( %postun, %preun ) sprawdzi, czy $ 1 jest równa "0", jeśli tak to w pełni usunie, jeśli nie jest on albo uaktualniony lub zainstalowany - siła tej samej paczki.

Aby przetestować ten argument, co następuje 'jeśli' użyte jest stwierdzenie:

%postun
if [ $1 = 0 ]; then
    // Do stuff specific to uninstalls (dla specyfikacji usunięcia)
fi
if [ $1 = 1 ]; then
    // Do stuff specific to upgrades (dla specyfikacji uaktualnienia)
fi

Pojedynczy test jest zatem wystarczający, aby połączyć prawo działania w odpowiednim czasie.

Filetriggers

Począwszy od Mandriva Linux2009.0, rpm filetriggers są stosowane do odciążenia powtarzalnych zadań, takich jak "%post -p /sbin/ldconfig" lub "%update_menus".

Więcej makr

Gdy budujesz RPM dla Mandriva Linux, masz więcej makr by uprościć plik specyfikacji.

  • Obsługa stron informacyjnych. Najlepszym nauczycielem jest przykład:
%post
%__install_info %{name}.info

%preun
%__install_info %{name}.info
%post
%{update_menus}

%postun
%{clean_menus}
  • Obsługa czystej internacjonalizacji. Najlepszym sposobem jest wejście przez pliki .mo gdzie zazwyczaj pliki są w katalogu /usr/share/locale/.., ale używaj specjalnych makr w sekcji %install, które wypełni specjalny plik jak to:
%find_lang %{name}

Wtedy będziemy korzystać z pliku w pliku listy:

%files -f %{name}.lang
  • Budowa makr. Budowa makr %configure i %makeinstall ana chwilę obecną są dość duże. Określają one prefiks, ale też wspólny katalog (np. bindir, datadir, itd.); w tym zakresie, w którym pracują bezbłędnie z małymi i średnimi paczkami, ale zawsze potrzebują trochę uwagi co do reszty. Makro %make wykonuje polecenia make -j<num> z odpowiednią opcją skali, również z wieloprocesorowymi. Jeśli musisz ręcznie połączyć ze skryptem ./configure pamiętaj aby NIGDY nie hardkodować architektury; makro %{targetplatform} jest do tego celu (lub nawet %{targetcpu} , w razie potrzeby).
  • Budowanie serwerów. Do budowania bezpieczniejszych serwerów skorzystamy z określonego makra, %serverbuild, które zostanie użyte zanim przystąpimy do faktycznego budowania. Pozwala to na bezpieczniejszą flagę optymalizacji. W sekcji %build często będzie wyglądać następująco:
%build
%serverbuild
%configure
%make
  • Skrypt makra. Po zainstalowaniu pakietu, który zapewni mu własne skrypty (pliki w katalogu /etc/init.d ), musi być dodane poprzez dialog, który wygląda jak chkconfig --add .., ale nie w przypadku uaktualnień , musi zostać ponownie uruchomiony, jeśli jest już uruchomiona; gdy odinstalowywane, podobne (przeciwne), rzeczy należy zrobić, mamy określone makra, by to zrobić bez usterki:
%post
%_post_service <initscript-name>

%preun
%_preun_service <initscript-name>
  • Obsługa ghostfiles. Głównie gry, czasami używają pakietów różnych plików, które mogą nawet być nieobecne. Właśnie tam ghostfiles są przydatne. Oto przykład:
%install

(...)

mkdir -p $RPM_BUILD_ROOT/var/lib/games
touch $RPM_BUILD_ROOT/var/lib/games/methanescores

%post
%create_ghostfile /var/lib/games/powermanga.hi root games 664

(...)

%files
%attr(664, root, games) %ghost /var/lib/games/powermanga.hi

Makro %create_ghostfile powiększy się:

if [ ! -f /var/lib/games/powermanga.hi ]; then 
  touch /var/lib/games/powermanga.hi
  chown root.games /var/lib/games/powermanga.hi
  chmod 664 /var/lib/games/powermanga.hi
fi 
  • .desktop / rzeszenie odwzorowywania typu MIME: system menu XDG umożliwia ustawienie kojarzenia między aplikacją a typem plku .desktop. Update-desktop-database należy uruchomić narzędzie .desktop jeżeli jest zainstalowany / odinstalowany w systemie, używając makra, jak pokazano w następującym przykładzie:
%post
%update_desktop_database

%postun
%clean_desktop_database
  • Freedesktop.org typ MIME bazy danych: bazy danych wykorzystywane do listy wszystkich dostępnych typów MIME, i/lub z magicznym rozszerzeniem pliku wzorca powinny być aktualizowane przy użyciu makra, jak pokazano w następującym przykładzie:

%post
%update_mime_database

%postun
%clean_mime_database
  • Ikona pamięci podręcznej: wszystkie pakiety ikon spedycji przetrzymywane są w /usr/share/icons/hicolor (lub innych katalogach ikon motywu Freedesktop, w takich jak /usr/share/icons/gnome lub /usr/share/icons/crystalsvg ) musisz aktualizować ikonę pamięci podręcznej, jak podano niżej (ikony przechowywane w /usr/share/icons, /usr/share/icons/mini lub /usr/share/icons/large nie są objęte tym wymogiem):
...
%file
...
%{_iconsdir}/hicolor/*
%{_iconsdir}/crystalsvg/*
....

%post
%update_icon_cache hicolor
%update_icon_cache crystalsvg

%postun
%update_icon_cache hicolor
%update_icon_cache crystalsvg
  • rejestracja schematów GConf: schematy GNOME GConf muszą być zainstalowane/odinstalowane za pomocą następującego makra:
...
# each schema key here corresponds to a file named /etc/gconf/schemas/<key>.schemas
%define schemas apps_gnome_settings_daemon_default_editordesktop_gnome_font_rendering desktop_gnome_peripherals_keyboard_xkb fontilus themus

%post
%post_install_gconf_schemas %{schemas}

%preun
%preun_uninstall_gconf_schemas %{schemas}
  • Scrollkeeper aktualizacji bazy danych: scrollkeeper danych (używany do indeksu dokumentacji) powinien być aktualizowany po zainstalowaniu .omf podobny do tego pliku:
...
%post
%update_scrollkeeper

%postun
%clean_scrollkeeper

Interakcje z urpmi i rpmdrake

Czasem konieczne jest ostrzeżenie użytkownika o czymś ze szczególną starannością, które powinny zostać podjęte podczas upgrade'u lub zainstalowania specjalnej wersji pakietu. rpmdrake-2.1.3-11mdk wyższe wspiera ten sposób: on wyszukuje w RPM plików tekstowych o nazwie README.install.urpmi, README.update.urpmi lub README.urpmi, i wyświetla je.

README.install.urpmi wyświetlany jest tylko dla zainstalowanych pakietów; README.update.urpmi tylko na zaktualizowanie istniejących pakietów; README.urpmi jest wyświetlany w obu przypadkach.

Grupy Mandriva Linux

Wykaz grup można znaleźć na grupy RPM

Mandriva Linux ważne licencje

Zobacz na licencje Mandrivy


Alternatywnie: checkinstall

W bardzo prosty sposób można zbudować RPM dla osobistego użytku, trzeba zainstalować pakiet checkinstall; kompilacja ze źródeł; nie jak zwykle (./configure && make && sudo make install), ale po prostu zastąpić make install krokiem checkinstall. To pozwoli zautomatyzować budowanie RPM i jest bardzo proste w użyciu. Zaletą jest to, że nie musisz w ogóle pomijać menedżera pakietów podczas kompilacji ze źródeł. ( Prawdopodobnie to dobry pomysł, jednakże aby zbudować RPM "właściwie", jeśli zamierzasz dystrybuować je użyj powyższego opisu.)

Niektóre linki

Inne interesujące źródła informacji Mandriva RPM

W innych językach