Unelte utilizator

Unelte site


playground:playground

PlayGround

Ghidul pentru împachetat rpm (Rosa edition)


Acest tutorial are scopul de a ajuta persoanele care doresc să construiască pachete RPM,
pentru distribuţie GNU / Linux Rosa.
În special, se va evidenția în ce fel pachetele sunt uşor diferite de pachetele RPM folosite de către
alte distribuții GNU / Linux bazate pe rpm.
Acest document va fi folosit atât de către dezvoltatorii de ROSA, cît și de către cei externi.
Pe linga traducerea ghidului încerc sa adaug și comenzile de lansat din shell (konsola)
pentru a vă familiariza cu aceasta.

Împachetarea RPM ca root este periculoasă, deoarece fișierele binare sunt instalate pe sistem înainte de a fi împachetate, prin urmare, trebuie să fie efectuată întotdeauna ca utilizator normal, astfel încât nu va polua accidental sistemul vostru.

Prefață

Se presupune că cititorul are cel puțin cunoștințe de bază adică ceea ce înseamnă ”Linux ready”,
ți că cunoaște deja comenzile de bază, structura de directoare și a folosit utilitarul rpm ,
cel puțin pentru instalarea pachetelor.
În acest document se va descrie pas-cu-pas crearea unui pachet rpm, care poate fi integrat
în distribuția Rosa Linux, fie pornind de la un pachet sursă rpm, fie pornind de la o sursă arhivată sau altele 1)
RPM înseamnă aproximativ trei lucruri:

  • un program destinat pentru a instala sau crea pachete,
  • un format utilizat în pachete (sursa sau binar), creat de programul de rpm,
  • un fișier numit pachet care conține fie un binar fie surse, împreună cu un antet de informații despre cum se va efectua instalarea / dezinstalarea programului

Utilitarul rpm este, din punctul de vedere al utilizatorului, un manager de pachete puternic.
Acesta acționează ca un „dirijor“ pentru orice acțiune pe pachetele rpm.
Printre altele, el poate:

  • instala, verifica sau actualiza un pachet plus dependențele sale,
  • în timpul instalarii unui pachet, pregătește programul instalat gata de utilizare,
  • restaureaza fișierele șterse accidental ce aparțin unui pachet,
  • verifică dacă un pachet este deja instalat,
  • aflarea cărui pachet aparține unui anumit fișier,
  • verifică instalarea curentă cu privire la îndeplinirea cerințelor de dependențe a pachetelor instalate,
  • altele

Din punctul de vedere al programatorului, rpm este un utilitar de împachetare,
care încapsulează, într-un fișier rpm unic, toate informațiile necesare pentru a instala un program pe o anumită platformă.

Description :
RPM is a powerful command line driven package management system capable of
installing, uninstalling, verifying, querying, and updating software packages.
Each software package consists of an archive of files along with information
about the package like its version, a description, etc.











Este important să se distingă de la început, diferența dintre pachetele sursa.rpm (.src.rpm) și binar(.<tipul_de_arhitectură>.rpm).
Sursa rpm conține (da, aţi ghicit), structura, sursa completa a programului original, plus tot ansamblul structural adăugat de împachetator,
cu scopul de a configura, compila și instala programul, care, în general, constă dintr-un fişier spec
(fișier folosit pentru a instrui utilitarul rpm care sunt operațiunile ce trebuie să le efectueze,
în scopul de a crea pachetul), împreună cu patch-uri,(dacă este cazul), și altele 2).
Pachetul binar conține binarul compilat, și toate fișierele (documentație, fișiere de configurare, icons, …),
care vor fi instalate pe sistemul destinat.
Acesta conține, de asemenea, procedura utilizată pentru a plasa fișierele
în locația lor corectă și pentru a efectua acțiuni, în scopul de a face programul operabil.

Necesarul și configurarea software

Noţiuni de bază

Deşi RPM a fost inițial conceput pentru Red Hat Linux de asemenea, el vine utilizat și de alte distribuții
bazate pe rpm :RosaLinux, MandrivaLinux, Suse, Fedora, etc., unde rpm este preinstalat pe aceste sisteme.
RosaLinux utilizează RPM5, un descendent din rpm pe care il găsiți Aici în aroma „vanilla“.

Rpm5 este retrocompatibil cu rpm4, și cu specificațiile pregătite pentru rpm4, (care este folosit de către
majoritatea distributiilor bazate pe rpm), deci și rpm4 ar trebui să fie compatibil cu rpm5,
cu condiția să respecte politica de împachetare Rosa Linux.

Împachetare pentru Rosa Linux

Construirea de pachete pentru Rosa Linux este întotdeauna supusă la patch-uri și mici îmbunătățiri la programul rpm.
Pentru a avea utilitarele actualizate, pentru construirea de pachete rpm, primul pas este descărcarea și instalarea
ultimei versiuni RosaLinux, după care prin intermediul gestionarului de pachete, următoarele utilitare:

  • Pachetul rpm, care este versiunea cu patch-uri de RPM5 (ar trebui să fie deja instalat);
  • Pachetul rpm-build care conține scripturi folosite pentru a construi pachete;
  • Rpmlint pachet care este folosit pentru a verifica validitatea a fișierului generat src.rpm.

Sau lansați comanda următoare într-un terminal root:


urpmi rpm-build rpmlint

Crearea infrastructurii pentru construit pachete

Pentru a construi pachete rpm, este nevoie de o infrastructura care va fi creata special de directorul home al utilizatorului,
infrastructură ce va fi creata cu urmatoarea comandă lansată ca și utilizator:


mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS/i586,RPMS/x86_64,RPMS/noarch,SOURCES,SRPMS,SPECS,tmp}









Asigurați-vă că structura nou creata este de urmatoarea forma:

  • ~/rpmbuild/BUILD: Director în care sursele sunt construite.
  • ~/rpmbuild/BUILDROOT: Director în care instalarea va fi simulată
  • ~/rpmbuild/RPMS: Conține directoarele pachetelor rpm , câte unul pentru fiecare arhitectură.
  • ~/rpmbuild/RPMS/i586: Conține pachetele rpm ptr arhitectura de procesor i586.
  • ~/rpmbuild/RPMS/x86_64: Conține pachetele rpm ptr arhitectura de procesor x86_64
  • ~/rpmbuild/RPMS/noarch: Idem pentru noarch, pachete independente de arhitectura procesorului.
  • ~/rpmbuild/SOURCES: Conține fișierele sursă (mypackage.tar.bz2, de exemplu, și patch-uri).
  • ~/rpmbuild/SPECS: Conține fișierele spec, pe care va trebui să le scriem noi.
  • ~/rpmbuild/SRPMS: Conține pachetele sursa-rpm, ( src-rpm), după împachetare.
  • ~/rpmbuild/tmp: Pentru jurnale 3) temporare, create de rpm la construirea pachetelor, scripturi care sunt generate efectiv în timpul împachetării,
    ele sunt generate în baza fișierului spec, și pot fi utile pentru debugging.

Nota:
Directoarele de arhitectura în
~/rpmbuild/RPM sunt necesare pentru rpm.
Dacă acestea nu sunt prezente,
veţi primi un mesaj de eroare.

Nu creati fișierul rpmmacros

Ghidurile pentru unele distribuții mentioneaza că ar trebui să se creeze un fișier ~/.rpmmacros
pentru a adăuga unele informații personale pachetelor, cum ar fi :%impachetator (packager), %furnizor (vendor), etc.
Nu faceți acest lucru, scripturile de împachetat ce rulează în interiorul sistemului de build atribuie aceste valori în mod automat.

Construirea unui pachet RPM

Dintr-o sursa-rpm (src.rpm)

Această parte a ghidului se referă, în general, la pachetele deja incluse în distribuție.
Cele mai noi pachete rpm pot fi găsite în cooker (versiunea de dezvoltare a distribuției),
pe mediile cooker, și poate fi găsit în:
TODO: verify mirror list:.

  • SRPMS (main, contrib, jpackage, altele) și în cadrul arhitecturii CPU (de exemplu, i586, x86_64, …);
  • media/main pentru pachetele main
  • media/contrib pentru pachetele contrib
  • media/jpackage pentru pachetele noarch (independente de arhitectura CPU)

Când găsiți un src.rpm pe care doriți să-l modificați pentru ROSA Linux, ajunge să lansați comanda ca și utilizator:


rpm -ivh mypackage.src.rpm









Acesta va instala toate fișierele src.rpm în directorul de RPM.
Puteți utiliza, de asemenea, urpmi pentru a descărca sursa:

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
















Constatam că rpm a instalat în structura rpmbuild fișierul sursă ktron-1.0.1.tar.bz2 și fișierul spec,
înainte de a construi o versiune mai nouă a unui pachet, s-ar putea reconstrui pachetul actual,
în scopul de a înțelege modul în care este compilat și daca compilează.
Comanda magică pentru a face acest lucru este rpmbuild cu opțiunea buildall:

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








Dacă compilarea rezultă fără erori, (compilare care poate dura chiar ore, pentru anumite pachete, cum ar fi kernel),
pachetele compilate ,se vor găsi dupa cum urmeaza, pachetele rpm in ~/rpmbuild/RPMS/i586, (sau ~/rpmbuild/RPMS/x86_64), și respectiv
src.rpm, în ~/rpmbuild/SRPMS/

Nota:
în continuare ghidul explică cum se iau atribute de root
și se instaleaza pachetul proaspat compilat, eu din motive de siguranță
sar acest pasaj și revin cu el în altă secțiune (ceva mai avansată) a ghidului








Jurnalul de compilare5) ar putea fi foarte lung,
și ar fi un bun exercițiu să fie păstrat pentru un studiu ulterior, el se poate gasi în ~/rpmbuild/tmp, și pentru consultarea
lui ghidul recomandă tee, în schimb eu recomand oricare dintre editoarele de text care vă este mai familiar :
utilitarul shell: „cat“ ,mcedit, vi/vim, gedit, kwrite toate iși fac treaba foarte bine.

În subdirectoarele ~/rpmbuild/BUILD de obicei, veți accesa sursele cu patchurile aplicate, (în cazul în care una sau mai multe patch-uri
au fost plaste în ~/rpmbuild/SOURCES), binare, librariile compilate, pagini de maual etc. Fișierul spec. descrie și instruiește surse și patch-uri care se aplică la ele, pentru a construi și instala pachetul .

Modificarea surselor în src.rpm nu este recomandată. ROSA Linux nu stochează fișiere src.rpm, ele se stochează ca fişiere .spec
și surse de însoțire într-un depozit de Git, iar fișierele src.rpm sunt generate pe sistemul de asamblare 6).

Din Surse primare (tarball)

De exemplu, dacă veți găsi un program interesant pe github sau SourceForge, sau creat de voi înșivă,
poate doriți să-l puneți la dispoziția tuturor utilizatorilor Rosa Linux, atunci cel mai bun mod de a o face este crearea un proiect în ABF,
și un fișier spec, care să corespundă standardelor și directivelor Rosa Linux.
În primul rând, descărcați arhivele cu surse, și le plasați în directorul ~/rpmbuild/SOURCES.

Verificări preliminare

Licenţă:
În ciuda prevalenței licențelor GPL, există în circulație și licențe non-GPL.
Verificați licența software-ului cu atenție pentru a determina dacă poate fi inclus în distribuție.
Nu se acceptă software închis (cu sursă închisă), (dar există unele excepții pentru club).
De asemenea, nu putem accepta software care nu ne permite să îl distribuim în mod liber.
Evitați aceste programe. O listă de licențe software acceptabile pot fi găsite pe ROSA Licensing Policy

Compresie tarball

Pentru a facilita întreținerea pachetului, este recomandat să utilizați original tarball fără modificări.
Dacă sursele oferă diferite variante de comprimare, vom alege cele cu extensia tar.bz2.
De evitat comprimarea patch-urilor în format text, (rezultate DIF ) și alte fișiere de configurare/scripturi/etc. care sunt în formatul text,
deoarece se va economisi foarte puțin spaţiu, în schimb se îngreunează procesul de control pentru a vedea modificările în diffs-uri pe Git
(care deja este o formă de compresie).

Notă:
Pentru pachetele critice și de securitate vă recomandăm să nu modificați sursa originala deloc,
în caz contrar acesta iși va schimba semnătura de integritate (checksum). Pentru aceste tipuri de pachete,
vă recomandăm să îl lăsați în formatul original, astfel încât atunci când se face verificarea cu md5sum/gpg ,
aceasta va corespunde valorilor menționate pe locația de descărcare.
Un exemplu de caz excepțional ar fi OpenSSH.

Fișierul spec

Fișierul Spec conține toate informațiile de care rpm are nevoie pentru a:

  1. Compila programul și construi fișierele rpm și src.rpm
  2. Instala, dezinstala și actualiza programul pe mașinile utilizatorilor finali

Faptul că aceste două tipuri de informații sunt combinate într-un singur fișier poate părea destul de ciudat începătorilor,
De fapt, acest lucru se datorează structurii programului-sursă, care conține deja aceste informații.
Procedura de instalare, în general, vine extrasă din procesul de instalare coordonat de make install, din structura sursei,
Pe scurt fișierul spec descrie o simulare a unei compilări și a unei instalari, dă indicații către rpm care din fișierele rezultate din această
compilare vor fi împachetate, în cele din urmă cum vor fi instalate aceste fișiere pe sistemul utilizatorului.
Comenzile sunt executate folosind shell-ul /bin/sh, deci comenzile: [-f configure.in] && autoconf sunt valabile.
Această parte a ghidului nu este destinata să explice în detaliu toate caracteristicile unui fișier spec.
Manualul Maximum RPM,7) explică în detaliu aceasta.
Tot ce se intenționează să se faca aici este trecerea în revistă rapid a tuturor caracteristicilor
utilizate într-un exemplu spec, standard ROSA .
Acesta este un exemplu din mediul cooker. Puteți, de asemenea, incerca să folosiți fișierele noastre spec ca șablon, pentru a scrie un spec propriu

%define name gif2png
%define version 2.0.1

Name: %{name}
Summary: Tools for converting websites from using GIFs to using PNGs
Version: %{version}
Release: 1
Source0: http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2
Source1: %{name}-%{version}-rosa-addon.tar.bz2
Patch0: gif2png-2.0.1-bugfix.patch
URL: http://www.tuxedo.org/~esr/gif2png/

Group: Applications/Multimedia
License: MIT-like
Requires: python

%description
Tools for converting GIFs to PNGs. The program gif2png converts GIF files
to PNG files. The Python script web2png converts an entire web tree, also
patching HTML pages to keep IMG SRC references correct.

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

%build
%configure
%make
%install
%makeinstall

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

# Omiteti %changelog cind construiti pachete RPM pentru ROSA!Acesta este doar un exemplu!
%changelog
* Mon Nov 02 1999 Camille Begnis camille@mandrakesoft.com 2.0.1-rosa2012
- Upgraded to 2.0.1

* Mon Oct 25 1999 Camille Begnis camille@mandrakesoft.com 2.0.0-rosa2012
- Specfile adaptations for Mandrake
- add python requirement
- gz to bz2 compression































































Acum haideti să analizăm în detaliu fiecare linie din acest spec, de reținut că % de la începutul anumitor rânduri poate avea semnificații diferite, de la caz la caz, cum ar fi:

  • începutul unei secțiuni (prep, build, instal, etc.)
  • un script macro inclus în uneltele de build, (setup, patch)
  • o directivă utilizată de o secțiune specială (defattr, doc,…)


Secțiunea antet

(Header section)

Secțiunea antet trebuie să conțină etichete standard cu numele, versiunea și release:

Name: gif2png
Version: 2.0.1
Release: 1









Aceste trei linii definesc macrocomenzi automate care pot fi utilizate în multe din următoarele secțiuni din fișierul spec,
%{name}, %{version} și %{release}. Rețineți că anumite pachete pot avea voci învechite % mkrel macrocomandă
care pur și simplu este redundanta în ROSA.
Numele pachetului este utilizat în package's name și în baza de date a pachetului pe calculatorul utilizatorului final.
Aceasta linie va fi redata în managerul de pachete ca un nume de pachet.
Acum vom intra în amanunt în ceea ce privește numele pachetului și cum este format, este important să se respecte întotdeauna
acest standard pentru a face munca ta ințeleasă altora.
Există, de asemenea, unele Tag-uri despre care s-ar putea să doriți să știți, dar care nu sunt în acest exemplu de fișier spec.
Nu trebuie să vă amintiți toate acestea, la începutul carierei de packager, vă veți familiariza cu timpul!

  • Un pachet binar va fi denumit: nume-versiune-release-rosa2012.arhitectura.rpm 8),(rosa2012 desemnează DISTTAG și DISTEPOCH și se adaugă automat de rpmbuild)
  • Un pachet sursa-binar va fi denumit: nume-versiune.src.rpm9) (in exemplul nostru gif2png-2.0.1.src.rpm)

Numele ales, va fi numele principal al pachetului binar, în cazuri excepționale se poate defini un alt nume.
Versiunea este numărul din surse (inainte de aplicarea patch-urilor), și este numărul de versiune în numele fișierului arhivă original: nume-versiune.tar.gz.10)
Release este un număr care vine incrementat la fiecare pachet nou construit.
Acest lucru poate fi din cauza unor patch-uri aplicate la surse, sau o modificare la fișierul spec, adăugarea de o pictogramă, etc.
Numele pachetului rpm este generat automat de vocile:

  • Release:
  • Versiune:
  • Nume:



Summary: tools for converting websites from using GIFs to using PNGs








Aceasta este o linie de descriere a pachetului .
Ar trebui să fie mai mică de 80 de caractere (a se vedea sintaxe fisier spec. ).




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








Această linie indică rpm, care este fișierul sursă de utilizat pentru construirea acestui pachet.
Rețineți că numele fișierului este precedat de un URL complet (care este opțional), și indică site-ul de origine,
în cazul în care sursa originală este disponibilă; rpm, va elimina URL-ul, va ține cont numai numele fișierului,
și va căuta doar în directorul SOURCES. Deși se spune că URL-ul complet este opțional,este foarte recomandat ca să
se poata ști unde pot fi găsite noi surse în cazul în care se va dori actualizarea pachetului de către utilizator.
Acest lucru va permite instrumentelor, cum ar fi rpmbuildupdate de a reconstrui automat versiuni noi, ( a se vedea rpmbuildupdate)
Când există mai mult de un fișier sursă, utilizați alte linii cu

  • Source1: …
  • Source2: …





Patch0: gif2png-2.0.1-bugfix.patch








Există două motive pentru această etichetă opțională:

  •  Ați reparat un bug la sursele programului. Deci, ați generat un fișier de corecție11) care se aplică la surse înainte de compilare.
  •  Ai fost avertizat de existența unui patch pentru versiunea aceasta, de undeva de pe net, sau cherry-picked 12)

Nota:
Patchul trebuie să fie plasat în directorul cu sursele, SOURCES,
ca și in cazul surselor, pot exista mai multe patch-uri,
acestea vor fi numite Patch1, Patch2, etc








Patchurile13) listate ca și Patch0 în secțiuni NU se vor aplica automat, a se vedea mai jos cum pot fi aplicate.











Această linie (opțională, dar recomandată), indică home page-ul programului.



Group: Multimedia









Aceasta linie indică rpm, care va fi grupul de destinație în stuctura de pachete.
Această funcție este utilizată de managerii de pachete cu interfață grafică cum ar fi rpmdrake.
Structura completă a grupurilor utilizata de Rosa, este obligatorie, în caz contrar pachetul va fi plasat greșit
și va contrasta cu altele, în stuctura de pachete a sistemului sau
va fi de negăsit de interfețele grafice ale managerului de pachete.



License: MIT-like









Această etichetă (drepturi de autor) definește licența aleasă de către titularul drepturilor de autor, care se va aplica software-ului împachetat.
În cele mai multe cazuri, este GPL. A se vedea Politica de licențiere pentru lista completă de licențe valabile.


Requires: python









Această linie a fost adăugata ptr că unul dintre programele incluse în pachet este un script Python,
și deci are nevoie de python să fie executat.
Puteți delimita un minim opțional (sau egal), în versiune, de exemplu:

Requires: python >= 2.7.






Dacă pachetul conține fișiere executabile legate de bibliotecile C sau C++, astfel de „Requires“, sunt generate de rpmbuild automat.


%description
Tools for converting GIFs to PNGs. The program gif2png converts GIF files
to PNG files. The Python script web2png converts an entire web tree, also
patching HTML pages to keep IMG SRC references correct.









Aceasta este o etichetă cu totul specială în interiorul antetului fișierului spec, pentru că este un text complet format din linii diferite,
dacă este necesar paragrafe. Aceasta conține descrierea completă a software-ului instalat în scopul de a ajuta utilizatorul să decidă dacă vrea
să instaleze pachetul sau nu. Pentru a îmbunătăți lizibilitatea, %description pot avea traduceri de sinteză și
sunt stocate într-un fișier special, numit <package>. Po.
Această metodă presupune că toate textele în interiorul unui fișier spec sunt scrise în limba engleză.
Cu toate acestea, pot fi pachete destinate pentru o anumită limbă (ispell-de, de exemplu).
În acest caz, se recomandă să aibă textul în două limbi: engleză și în limba pachetului special și
veți utiliza tag-uri speciale pentru acest lucru:

Summary(de):
%description -l de






Secțiunea Prep


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









În această secțiune, este scris primul script executat de rpm. Rolul său este de a:

  • crea un nivel superior14) în directorul de build (în BUILD)
  • despacheta sursele originale în directorul de build, (în BUILD)
  • aplica eventualele patchuri la surse

Acesta poate fi urmat de orice comandă de ambalare dorește packagerul, în scopul de a obține sursele într-un stadiu adecvat compilării.

%setup -q -a 1






Acesta este un macro-script inclus în uneletele rpm care:

  • Mută locația în structura directoarelor de build (comanda cd) 15)
  • extrage sursa/sursele (în liniște, -q)
  • modifică permisiunile și proprietarul fișierelor sursă

În mod implicit vine extrasă prima sursă; trebuie să utilizați parametri pentru orice alte surse, în exemplul nostru - 1 spune că dorim, de asemenea, extracția sursei numărul 1.

Există alte switch-uri interesante care pot fi folosite cu macroul de %setup:

  • -C nume : Creeaza mai întâi un director principal unde va extrage sursa arhivata. Aveți nevoie de acest lucru în cazul fișierelor arhivate direct fără un container/director
  • -D : Nu se șterge directorul înainte de despachetare. Acest lucru este util numai dacă aveți mai mult de un macro de configurare. Ar trebui să fie utilizat numai în macro-uri de configurare care urmeaza primului %setup,(dar niciodată în primul).
  • -T : Această opțiune suprascrie acțiunea implicită de dezarhivare a sursei și necesită un -b 0 sau un -a 0 pentru a obține fișierul sursă principal dezarhivat. Aveți nevoie de acest lucru când există una sau mai multe surse secundare.
  • -n nume : în cazul în care numele de rpm este altul decât cel al Sursei dezarhivate, utilizați acest parametru. De exemplu: dacă numele este un program de rpm-versiune-rel și sursa dezarhivată programul-versiunea-data, procesul de build nu va fi capabil de a se muta (cd) în directorul programului-versiune, astfel cu -n program-versiune-data, instruim rpm care este noul director în care va continua procesul.

%patch0 -p1






Este un macro responsabil pentru aplicarea de patch-uri la surse. Parametrul “-p <num>“ este trecut la programul de patchuri.
Imaginați-vă că ați avut un alt patch declarat în Sectiunea Antet Patch1: .. , trebuie să adăugați o altă linie:% patch1- p1.
Adăugarea unui -b.suffixul_vostru ar fi, de asemenea, frumos, așa puteți lăsa pe alții sa știe ce face, sau cine a facut patchurile.
De exemplu, în cazul în care Fred a facut un patch, atunci el ar putea deveni %patch -p1 -b.Fred, și dacă Barney are un patch,
atunci acesta ar putea fi %patch -p1 -b.Barney .

Secțiunea Build

%build






Această secțiune va conține script-ul responsabil de build-ul efectiv a software-ului.
Se compune din comenzi emise atunci când se efectueaza construirea unui pachet dintr-o sursă dezarhivata.

%configure






Această linie se va utiliza pentru configurarea surselor autoconfigurante.%configure emite comanda ./configure
cu multe alte flaguri cum ar fi:

export CFLAGS=„$RPM_OPT_FLAGS“






înainte de configurare, și opțiuni cum ar fi:

i586-mandrake-linux –prefix=/usr –datadir=/usr/share






etc.
Uneori, aceste argumente nu sunt acceptate de către script-ul de configurare. În acest caz, trebuie să descoperiți motivul, și dați ./configure
cu parametrii adecvați. Putem să apelăm o platforma de destinație la apelul de configurare, (dacă este acceptată), cu: with %{targetplatform}
desigur, specificațiile arhitecturale pentru o arhitectura trebuie evitate în spec; de exemplu ix86, acest lucru include și i586-Mandrake-linux,
așa cum se arată în exemplul de mai sus.

Nota:
Veți avea nevoie de pachetul de libtool ptr a utiliza
%configure, pentru build de biblioteci partajate.








La compilarea și/sau testarea, pachetului ar trebui să se verifice ca platforma arhitecturală de destinație este de fapt i586, în special, atunci când
compilarea se efectuează pe un tip de procesor cu arhitectura superioară, comportamentul implicit al scriptului de configurare este de a descoperi
arhitectura de procesor, și de a optimiza compilarea pentru ea. Obiectivul macro-scriptului %configure, este de a evita acest comportament.

%make






Acesta este un macro simplu care efectuează de fapt make cu parametru multiprocesor adecvat sistemului vostru: -j<numar>

Pentru obliga folosirea xmkmf, ar trebui să înlocuiască %make cu următoarea comanda:

make CDEBUGFLAGS=„$RPM_OPT_FLAGS“ CXXDEBUGFLAGS=„$RPM_OPT_FLAGS“











Dar pentru majoritatea cazurilor, ( nu toate), este suficient %make.

Secțiunea Install

%install






Această secțiune va conține script-ul responsabil pentru instalarea simulată în directorul %{buildroot},
și va conține toate comenzile necesare pentru a definitiva rularea software-ului pe sistemul utilizatorului.

%makeinstall






Această linie în cele din urmă instalează software-ul în directorul de instalare a simulărilor pentru sursele autoconfigurate, extins înseamnă “make install“ cu multe opțiuni,
în scopul de a instala în directorul de simulare, %{buildroot}, exemple de opțiuni:

prefix=%{buildroot}/%{_prefix} bindir=%{buildroot}/%{_bindir}






etc.
În unele cazuri, scriptul de configurare va fi parțial corupt și ar putea fi necesară analizarea Makefile
pentru a ghici, parametri suplimentari pentru a obține o instalare corectă.
Una dintre cele mai comune este opțiunea:make DESTDIR=%{buildroot} install
Pentru a economisi spațiul pe disc și timpul de descărcare, Rosa folosește LZMA pentru a comprima manuale 16) și pagini info 17).
Cu toate acestea, acest aspect este tratat în mod direct de programul personalizat Rosa rpm.
Pentru a instala fișiere suplimentare cu permisiuni adecvate, avem la îndemână comanda install
În această secțiune, trebuie să eliminați, de asemenea, din %buildroot fișierele pe care nu le vor instala.
Iată un fragment dintr-un fișier spec:

# Don't install READMEs twice
rm -f %{buildroot}%{perl_vendorlib}/urpm/README*







După ce secțiunea %build a finalizat executarea acestuia, vor rămâne doar fișierele care vor fi instalate în sistem.
Toate celelalte fișiere trebuie înlăturate.
acum fișierele fiind pregătite pentru a fi împachetate în rpm.

Secțiunea Clean

Nu adăugați %clean in fișierele spec Rosa, folosiți, în schimb, rpmbuild –clean …

Secțiunea Files

%files






Această secțiune cuprinde o listă de fișiere care vor fi instalate pe un sistem atunci când utilizatorul instalează pachetul.
Aceste fișiere sunt reperate în directorul nostru de simulare în cazul în care un pachet a fost „instalat“ în timpul %build.
Fiecare fișier din directorul de instalare ar trebui să fie enumerat exact, o singura dată în secțiunea %files




corectat pina aici






Lista de fişiere trebuie să fie scrise de mână în fişierul spec.
Acesta poate fi realizata prin listarea tuturor fişierele create de rpm în directorul build.
Pentru de a face acest lucru, se va lansa rpmbuild -bi nume.spec în scopul de a opri procesul de build exact după instalarea simulata.
dupa care se va cauta în directorul de instalare a simularii:

~/rpmbuild/BUILDROOT/gif2png






(in cazul de fata), pentru a vedea ce fişiere vor fi introduse în pachet (de cele mai multe ori, se vor introduce toate).
De retinut că nu ar trebui să utilizaţi find pentru a construi o listă de fişiere
ci fisierele vor fi listate in mod explicit.(In asa fel se vor detecta erorile 18) in versiunile viitore.
Singurele excepţii sunt localizările, pentru care ar trebui să utilizaţi:
%find_lang %{name} in sectiunea %install, si sa inlocuiti %files cu %files -f %{name}.lang

Nota:
Despre structura de directoare: Fisiierele instalate de pachet „ar trebui“ să fie conforme recomandările de la FHS








%defattr(0755,root,root)

19)




Această etichetă defineşte atributele aplicate la fiecare fişier care va fi copiat pe sistemul utilizatorului.Cele patru argumente date înseamnă:

  • - : Toate atributele pentru fişierele mentionate rămân neschimbate,
  • root : proprietarul fişierului este root,
  • root : grupul la care apartine propritarul fişierului este root
  • 0755 : atributele aplicate la toate directoarele deţinute de acest pachet sunt 0755 (rwxr-xr-x).

%doc README NEWS COPYING AUTHORS






Tag-ul special %doc, desemnează fişierele ca fiind parte a documentaţiei pachetului.Fişierul, mentionat mai sus, va fi plasat în:
/usr/share/doc/gif2png-2.0.1/. Acest director va fi, de asemenea, creat automat tot de catre %doc.
Fişierele specificate de %doc se refera la sursa dezarhivata din BUILD, (si nu la directorul de simulare a intalarii).

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







Se recomanda listarea fiecarui fişier de manual 20) sau informaţii 21) separat. De asemenea, poate va intrebati de ce este listat gif2png.1* in loc de
gif2png.1.lzma, acest lucru este făcut pentru a decupla tipul de arhivare a paginilor de manual,
de numele fişierului în spec, şi pentru a păstra compatibilitatea cu alte sisteme care
ar putea utiliza gzip în loc de compresie lzma .
Dacă găsiţi astfel de referiri la orice tip specific de compresie în fişiere spec, pot fi schimbate cu un wildcard.
In majoritatea cazurilor poate fi utilizat chiar si: %{_mandir}/man1/*, acest wildcard va include
toate fişierele pe care le pote găsi.

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







Dupa cum se poate vedea exista macro-uri pentru fiecare tip de parcurs necesar.Aici sunt cele mai des folosite macrosuri,
(cautati in fişierele : /usr/lib/rpm/macros, /usr/lib/rpm/macros.d si /etc/rpm/macros.d
pentru mai multe detalii):

%{_prefix} , %{_bindir} , %{_sbindir} , %{_datadir} , %{_libdir} , %{_sysconfdir} , %{_mandir} , %{_infodir}






Pentru a utiliza macro-uri in pachetele jocuri folositi:

%{_gamesbindir} , %{_gamesdatadir}






Există, de asemenea,macrocomenzi,specifice pe subsistem, utilizate atunci cind impachetarea se refera la un anumit grup de impachetare,
aceste macro-uri disponibile în Rosa sunt descrise în politicile de ambalaje corespunzătoare, de exemplu, macro-uri utilizate pentru aplicaţiile KDE
pot fi găsite la pagina de KDE4 Politica impachetare

Sectiunea Changelog

NOTA:
Aceasta este doar o informaţie cu caracter general cu privire la Secţiunea Changelog.
NU ADAUGATI Changelog in fisierul spec ,acesta va fi generat automat din mesajele
„commit“ de catre sistemul de control al revizuirilor22).








Generalitati Changelog

%changelog






Această secţiune este utila ptr a urmări diferite modificări aduse pachetului.
Fiecarei noi versiuni a pachetului trebuie să ii corespundă un paragraf în această secţiune,
precum şi o creştere a numărului de release (dacă numărul de versiune23) nu este superior).

Commit logs

Informaţiile din această secţiune sunt generate automat din jurnalele „commit“ SVN.
Fiecare linie a jurnalului devine o linie care începe cu o cratimă (adugata în mod automat), şi descrie detaliile schimbărilor
aduse de acest „commit“ .“Commit“-urile vor fi grupate automat în funcţie de numele dvs. şi adresa de e-adresa de mail asociată
accesului in contul SVN.
Pentru a ominte o linie in jurnal, se adaugă „SILENT:“ la început , de asemene liniile fara continut nu vor aparea in jurnal.

Pentru a face o linie care nu apar în jurnal, se adaugă „SILENT:“ la început de el. Linkes goale sunt de asemenea ignorate.

Impachetarea propriuzisa

Ajunsi la acest punct , fisierul spec este complect, si putem trece la construirea efectiva a pachetului tastind:

rpmbuild -ba mypackage.spec






Puteţi adăuga, de asemenea,–clean opţiunea care curăţă directorul BUILD după terminarea impachetarii.
Există două posibilități de exit pentru ultima linie din proces:

  • Probabilitatile unui rezultat +024) sunt 0.01%
  • Probabilitatile unui rezultat cu un rezultat diferit25) 99.99%

Sunteţi în a doua categorie? Felicitări, aţi trecut testul, nu sunteti extraterestri…
Acum va trebui sa rezolvam erorile , pentru asta , trebuie verificate opţiunile de build26)
pentru a depana27) munca efectuata pina acum, ajutati-va prin consultarea la spec-urilor altor persoane “, etc.
Cel mai curat mod ptr tentativele urmatoare erorii este: rpmbuild -bs –rmspec –rmsource (pentru a elimina resturile din buildul precedent, si a genera un pachet rpm-sursa28))
dupa care se va lansa rpmbuild –rebuild.

Optimizarea Impachetarii

Când vine lansata comanda pentru a construi pachetul, cu siguranta ati intimpinat urmatorul mesaj: “foo-devel is necessary for foo2“.
Acest lucru înseamnă că are nevoie de informaţii din alte pachete utilizate pentru dezvoltare 29) (de obicei, fişierele denumite foo.h).
Dacă nu aveţi acestea, compilarea se va opri sau anumite caracteristici vor lipsi din pachet.
Sistemul pe care sunt construite toate pachetele oficiale (Sistemul de build ROSA), 30) are multe pachete devel preinstalate.
În cazul în care una nu este declarată în fişierul SPEC şi este obligatorie, pachetul va fi construit oricum pe cluster-ului.
Aceasta va funcţiona, dar lipsa acestor informaţii, împiedică buildul pe masini unde lipseste pachetul-devel,
făcând depanarea31)/actualizarea mult mai dificilă.
Consultind site-ul web al pachetului, se vor oferi informaţii despre componentele necesare (dar nu întotdeauna).
Ptr a avea o idee despre “BuildRequires lipsă“ se începe de impachetarea cu elementele de bază folosind numai pachetele devel instalate:

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

După care, instalaţi doar pachetul de dezvoltare32), relativ pachetului cerut de comanda rpm build. La lansarea buildului, urmăriţi cu atentie mesajele: “checking for..

Dacă se observa ceva de genul “checking for foo… foo.h not found“, aceasta înseamnă că un header33) necesar, nu a fost gasit
pe sistemul dumneavoastră. Acum se va cauta pachetul devel care conţine “foo.h“,

Atentie: puteţi găsi mai mult de un pachet care conţine ceea ce căutaţi.
Asa ca alegeti pachetul cel mai evident.
Nu alegeti un pachet apatinind grupului Network, atunci când buildul este o aplicaţie de sunet, (de exemplu).








Dupa care, se instaleaza pe sistemul de build şi se va adauga numele său în secţiunea BuildRequires a fişierului SPEC.
Headerurile lipsa pot fi găsite si în timpul compilării în sine. Dacă compilarea se opreşte, cu eroarea missing „foo.h“ se aplică aceeaşi metoda de mai sus.
Dacă doriţi să instalaţi toate BuildRequires ale unui pachet rpm (pentru testing, de exemplu), lansati: urpmi –buildrequires package.rpm.

Testarea unui pachet RPM

Teste de bază

Primii pasi de efectuat:

  • Pachete RPM nou create sint în directoarele corespunzătoare cu numele corect?(in ~/rpmbuild/SRPMS/ si ~/rpmbuild/RPMS/i586/)
  • Informatiile rezultate in urma lansarii comenzii: rpm -qlivp –changelog mypackage.(src.)rpm, sint corecte ?

Lintarea pachetelor

34)

Atentie: Veti avea nevoie si de rpmlint-mandriva-policy
instalam pachetele in felul urmator:
# urpmi rpmlint rpmlint-mandriva-policy








Pentru a efectua acest test trebuie sa fie instalat rpmlint, care va efectua anumite teste de impachetare
Dacă rpmlint rapoarteaza erori, pachetul va fi eliminat din distributie, la fel dacă există prea multe avertismente de un anumit tip,
chiar dacă avertismentele nu provoaca esuarea constructiei pachetului, ar trebui să se acorde o atenţie marita
şi să se încerce să se elimine cât mai multe posibil.
Pentru a executa verificarea, tastaţi rpmlint nume_pachet.<arhitectura>.rpm și vor fi emise anumite informatii si un raport privind pachetul specificat.
Pentru mai multă precizie, se va utiliza rpmlint -i . Ar trebui să se verifice rpm şi src.rpm.
Mai multe informaţii privind erorile, și rezolvarea, pot fi găsite :Impachetarea RPM,Probleme si rezolvari

Test de instalare

Acest test se poate efectua pe orice masina, dar este preferabil o masina diferita de cea pe care s-a facut impachetarea,
se efectueaza o actualizare sau o instalare, şi apoi se verifica:

  • Sint toate fişierele create unde era de aşteptat sa fie precum si permisele şi proprietarul?
  • Sint toate modificările de instalare, (dacă există), active?
  • Sint toate binarele executabile, documentaţia este accesibila utilizatorilor?

Perfectionisti încearca diverse instalări/dezinstalari pentru a verifica dacă toate caracteristicile aşteptate
sunt puse în aplicare în mod corect, de exemplu, lipsa pachetelor de dependenta necesare.
Dacă toate aceste teste sunt trecute cu succes, ar trebui să mergeţi la ultimul pas al procesului adica: publicarea pe medii.

Posibile erori si rezolvari

Ei bine, se pare că aţi citit acest ghid, care este un început bun.
Dacă nu găsiti răspunsurile aici, ar trebui să încercaţi, în ordinea dată:

  • 1.RPM-HOWTO oficial (instalat împreună cu programul de rpm pe sistemul dvs.);
  • 2.Manualul RedHat-Linux "Maximum RPM"
  • 3.Fisiere spec similare scrise de alti packageri ;
  • 4.Apelati la ajutorul membrilor din lista de discuţii Rosa-devel miling list,(in care va veti inscrie când începeti să participati la proiectul ROSA.)

Dacă aţi găsit informaţii care pot fi utile pentru alţii, în domeniul de aplicare al acestui document, nu ezitaţi să prezintati
propunerea dvs. de întreţinere si/sau editare a acestui document.

Sripturile Pre- si Post- instalare

Noţiuni de bază

Pachetul RPM este de fapt un pic mai mult decât o simplă arhivă care conţine fişiere care urmează
să fie extins în directoare specifice ale sistemului gazdă. Sistemul oferă o caracteristică importanta programatorilor, adica: scripturi pre- şi post-instalare.
Acestea permit packagerului a scrie o bucata de cod care va fi executat pe masina client la instalarea sau dezinstalarea pachetului.
Aceste script-uri sunt realizate ca orice comanda sh , si există patru adica:

  • %pre -Acest script este executat chiar înainte de instalarea pachetului pe sistem.
  • %post -Acest script este executat după ce pachetul este instalat pe sistem.
  • %preun -Acest script este executat înainte ca pachetul sa fie dezinstalat din sistem.
  • %postun -Acest script este executat doar după ce pachetul este dezinstalat din sistem.
1) binar, svn, git, etc.
2) nume.desktop, icon, etc
3) log
4) –ba este prescurtarea de la „build all“
5) build log
6) build system, ABF
7) a se vedea punctul 7
8) name-version-release-rosa2012.arch.rpm
9) name-version-release.src.rpm
10) name-version.tar.gz
11) patch
12) ales cel mai bun patch, ptr voi, de catre rosa labs
13) fisiere de corectie
14) top-level
15) change directory
16) man pages
17) info, readme, ChangeLog, etc
18) buguri
19) default attributes
20) man
21) info, readme, etc
22) git
23) version
24) build efectuat fara erori
25) erori de build
26) man rpmbuild
27) debug
28) .src.rpm
29) nume-devel
30) ABF
31) debugging
32) devel
33) foo.h
34) Linting the package
playground/playground.txt · Ultima modificare: 2012/08/21 16:53 de către symbianflo