Product SiteDocumentation Site

Cap. 10. Creare avansată pachete RPM

10.1. Definirea dependențelor pachetelor
10.1.1. Numirea dependențelor
10.1.2. Setarea premiselor
10.1.3. Numirea dependențelor de construcție
10.1.4. Generarea automată de dependențe
10.2. Setarea triggerelor
10.3. Scrierea scripturilor de verificare
10.4. Crearea subpachetelor.
10.4.1. Furnizarea informațiilor pentru subpachete
10.4.2. Definirea scripturilor pentru subpachete
10.4.3. Construirea subpachetelor
10.5. Creating Relocatable Packages
10.5.1. Setting up the prefixes
10.5.2. Define the files section
10.5.3. Problems creating relocatable packages
10.6. Defining Conditional Builds
10.6.1. Defining conditional macros
10.6.2. Using conditional blocks
10.6.3. Using architecture-based conditionals
10.7. Summary
Acest capitol acoperă:
Capitolul anterior a introdus fișierul spec RPM, care controlează cum sunt construite și instalate pachetele RPM. Acest capitol intră mai adânc în subiecte mai avansate despre fișiere spec cum ar fi utilizarea comenzilor condiționale și creare de pachete relocabile, începând cu instrucțiuni despre cum să specificați dependențele pachetelor

Definirea dependențelor pachetelor

Dependențele sunt una dintre cele mai importante părți ale sistemului RPM. Baza de date RPM caută dependențele între pachete pentru a vă permite să vă administrați sistemul mai bine. Dependențele apar când un pachet depinde de un altul. Sistemul RPM se asigură că dependențele sunt îndeplinite la actualizare, instalare sau la ștergerea pachetelor. Pornind de la acest concept simplu, RPM suportă patru tipuri de dependențe:
*Requirements (cerințe), unde un pachet cere o capabilitate asigurată de către alt pachet.
*Provides (asigură), o listă de capabilități asigurate de pachetul dvs.
*Conflicts (conflict), unde un pachet este în conflict cu o capabilitate asigurată de alt pachet
*Obsoletes (scos din uz), unde un pachet scoate din uz capabilitățiasigurate de un altul.
Referință încrucișată
Cap. 5, Package Dependencies are mai multe informații despre dependențe.Dependențele tip obsoletes sunt folosite de obicei doar când un pachet este redenumit, ca de exemplu pachetul apache care a devenit httpd, începând cu Red Hat Linux 8.0. Pachetul httpd scoate din uz pachetul apache.
Puteți enumera toate dependențele în fișierul dvs. spec. Cea mai folosită informație legată de dependențe este cea legată de cerințele unui pachet.

Numirea dependențelor

În fișierele dvs. spec puteți numi dependențele pentru pachetul dvs. Sintaxa de bază este:
Requires: capabilitate
În cele mai multe cazuri, capabilitatea ar trebui să fie numele unui alt pachet. Acest exemplu setează o dependență de tip requires. Acest lucru înseamnă că pachetul cere acea capabilitate. Folosiți o sintaxă asemănătoare și la alte tipuri de dependențe:
Provides: capabilitate
Obsoletes: capabilitate
Conflicts: capabilitate
Puteți pune mai mult de o singură capabilitate pe linia cu dependențele. De exemplu:
Requires: bash perl
Puteți folosi spații sau virgule pentru a separa capabilitățile. De exemplu:
Requires: bash, perl

Specificarea versiunii dependențelor

Puteți adăuga și informații despre versiune, de exemplu:
Requires: bash >= 2.0
Aceasta înseamnă că pachetul cere capabilitatea bash (un pachet) cu versiunea 2.0 sau mai sus. Aceeași logică se aplică la alte tipuri de dependențe.Spre exemplu:
Conflicts: bash >= 2.0
Acest exemplu arată că pachetul este în conflict cu toate versiunile bash 2.0 sau mai recente
Tabelul 11-1 enumerează comparațiile de versiuni pe care le puteți folosi.
Tabel 11-1 Comparații de versiuni dependențe
Comparație
Semnificație
pachet < versiune
Un pachet de versiune mai veche
pachet > versiune
Un pachet de versiune mai nouă
pachet >= versiune
Un pachet de versiune mai nouă sau la fel
pachet <= versiune
Un pachet de versiune mai veche sau la fel
pachet = versiune
Un pachet de versiune egală
pachet
Pachet la orice versiune
RPM suportă o sintaxă extinsă pentru compararea versiunilor. Acesta esteformatul complet:
Perioadă:Versiune-Lansare
De exemplu:
1:5.6.0-17
În acest caz, perioada este 1, versiunea este 5.6.0 iar lansarea este 17.În cele mai multe cazuri veți avea nevoie doar de versiune. Perioada permitemanevrarea versiunilor greu de comparat. Numărul de lansare nu este folosit aproape niciodată. Acest lucru are sens pentru că leagă o dependență de o anumităconstrucție a pachetului RPM mai degrabă decât de o versiune a programului în sine.Acest tip de dependență poate fi de folos doar dacă schimbați radical modul deconstrucție al unui pachet.

Creare CAPABILITIES virtuale

Dependențele sunt bazate pe capabilități, cele mai multe dintre acestea fiindpachete. Puteți crea capabilități virtuale, care sunt doar nume definite de dvs.De exemplu, pachetul sendmail asigură o capabilitate virtuală numită smtpdaemon.De exemplu:
Provides: smtpdaemon
Această capabilitate se referă la serviciul general SMTP pentru trimitereamesajelor e-mail. Nu există un fișier cu acest nume. Este doar o capabilitate,text arbitrar. Alte pachete cer această capabilitate, cum ar fi aplicațiafetchmail de descărcare și forwardare e-mail, și mutt, un client de mail.
Prin folosirea unei capabilități virtuale, alte pachete pot asigura capabilitatea, și, cel mai important, aplicațiile client pot cere această capabilitate fără a trebui să știe ce pachet asigură capabilitatea de a trimite mesaje e-mail. De exemplu, pachetele exim și postfix, agenți de transport mail ca și sendmail, pot asiguraaceeași capabilitate.
Notă
Desigur, veți dori să vă asigurați că aceste pachete intră în conflict unelecu altele.

Numirea dependențelor în motoare de scripting și module

Limbaje de scripting ca Perl sau Tcl permit module adiționale. Pachetul dvs. poate avea nevoie de unele dintre aceste module. RPM folosește o sintaxă specialăcu paranteze pentru a indica dependențe de module de scripting. De exemplu:
Requires: perl(Carp) >= 3.2
Aceasta indică o cerere pentru modulul adițional Carp pentru Perl, cu o versiune mai recentă sau egală cu 3.2.

Setarea premiselor

O premisă este similară cu o dependență require, doar că o premisătrebuie instalată înainte de un anume pachet. Specificați o premisă după cum urmează:
PreReq: capability
Puteți include dependențe cu număr-versiune, cum ar fi:
PreReq: capability >= version
De obicei, o PreReq: se comportă ca o Requires:, de fapt, directiva PreReq:există doar pentru a permite ordonarea manuală a dependențelor. RPM garantează că pachetul PreReq: va fi instalat înainte de pachetul care numește dependențaPreReq: .
Referință încrucișată
Cap. 13, Packaging Guidelines descrie problema comună detratare a dependențelor circulare folosind premise.

Numirea dependențelor de construcție

Pachetul dvs., odată construit, are un set de dependențe. Aceste dependențe sunt importante pentru oricine care instalează pachetul. Dar există și probleme cu dependențele la construirea pachetelor. Dependențele de construcție vă permit să precizați de ce este nevoie pentru a construi pachetul. Chiar dacă credeți că acest lucru e același cu ce este necesar pentru a instala pachetul, în mod normal nu este așa. Distribuțiile de Linux tind să împartă software-ul în pachete necesare la rulare și pachete pentru dezvoltatori (runtime și development)De exemplu, pachetul python conține runtime-ul necesar pentru executarea scripturilorscrise în Python. Pachetul python-devel asigură abilitatea de a scrie extensii ale limbajului Python
RPM vă permite să definiți dependențe în timpul construirii în fișierele dvs. spec folosind următoarele directive:
BuildRequires:
BuildConflicts:
BuildPreReq:
Aceste directive se comportă ca Requires:, Conflicts:, respectiv PreReq:, exceptând faptul că dependențele sunt necesare pentru construirea pachetului, nu pentru instalarea lui. De exemplu, pachetul dvs. poate avea nevoie de un compilator C pentru construcție, sau ar putea avea nevoie de un instrument special de construit sau o bibliotecă de dezvoltare

Generarea automată de dependențe

Pentru că multe dependențe sunt legate de bibliotecile shared, sistemul RPM va genera automat dependențe provide pentru orice fișier din pachetele dvs.care este obiect shared sau fișier .so. RPM va genera de asemenea dependențerequire pentru toate fișierele din lista %files care cer biblioteci shared.Pentru a realiza acest lucru, RPM folosește comanda ldd, care determină bibliotecile shared folosite de o aplicație.
în plus, scripturile find-requires și find-provides din /usr/lib/rpm pot determina dependențele scripturilor Perl, Python și Tcl și alte dependențe,cum ar fi dependențele pachetelor Java, în mod automat. Scriptul find-requiresdetermină dependențele requires automat, iar scriptul find-provides determină dependențele provides
Referință încrucișată
Cap. 13, Packaging Guidelines tratează oprirea generării automate a dependențelor.