Cum se creează un pachet tarball de cod pas cu pas

Dacă lucrezi cu Linux, mai devreme sau mai târziu vei da peste un fișier tarball de cod : acel fișier tipic .tar, .tar.gz sau .tar.bz2 care conține proiectul complet, gata de compilare sau împachetare. La prima vedere, poate părea puțin intimidant, dar odată ce înțelegi cum să-l creezi și să-l utilizezi, devine un instrument esențial în munca ta zilnică.

În acest ghid, veți învăța cum să creați un fișier tarball pas cu pas , cum să comprimați și să decomprimați cu tar, cum să pregătiți un proiect pentru distribuire ca și cod sursă și cum să duceți acel tarball un pas mai departe, împachetându-l ca .deb, .rpm sau chiar în formate universale precum Snap, Flatpak sau AppImage. Totul este explicat în detaliu, dar în termeni simpli, astfel încât să puteți pune în practică cu încredere.

Ce este mai exact un fișier tarball și de ce este folosit atât de des?

O arhivă tar este pur și simplu o arhivă creată cu instrumentul tar care grupează mai multe fișiere și directoare într-una singură. Inițial, „tar” provine de la Tape Archive , deoarece era folosit pentru a descărca date pe benzi, dar astăzi este folosit în principal pentru a împacheta codul sursă și a crea copii de rezervă.

Când vedeți extensii precum .tar , .tar.gz , .tgz sau .tar.bz2 , vedeți de fapt o arhivă tar plus un strat de compresie . Procesul tipic este: mai întâi, toate fișierele sunt incluse în arhiva tar, iar apoi acea arhivă tar este comprimată cu gzip (.gz), bzip2 (.bz2) sau programe similare pentru a reduce dimensiunea.

În ecosistemul GNU/Linux, fișierele tarball sunt folosite pentru a distribui codul sursă original al programelor , pentru a muta arbori de directoare mari între servere, pentru a face copii de rezervă ale site-urilor web sau ale datelor și pentru a partaja proiecte independent de distribuție (nu depind de .deb, .rpm etc.). De aceea sunt atât de universale.

Un punct cheie este că tar respectă permisiunile, proprietarii și structura directoarelor , ceea ce este esențial atunci când împachetați cod sau configurații care trebuie instalate exact așa cum sunt pe o altă mașină.

Comenzi de bază cu tar: creare, listare și extragere

Comanda tar este una dintre cele mai utilizate în Linux și, în ciuda numeroaselor opțiuni, este suficient să vă amintiți doar câteva pentru a vă ajuta să îndepliniți majoritatea sarcinilor zilnice. Sintaxa de bază urmează întotdeauna același model:

fișier tar.căi tar…

Printre cele mai comune opțiuni pentru lucrul cu fișiere tar se numără c, x, t, v, f, zyj . Fiecare combinație vă permite să creați, să răsfoiți sau să extrageți diferite tipuri de fișiere .tar, .tar.gz sau .tar.bz2 fără prea multă bătaie de cap.

Creați un fișier .tar simplu

Pentru a împacheta cod necomprimat, de exemplu directorul ~/projects/myprog-1.0 , puteți rula:

tar -cvf miprog-1.0.tar ~/projects/miprog-1.0

Opțiunile pe care le utilizați în această comandă tar sunt foarte tipice: c pentru a crea o arhivă nouă, v pentru a afișa ce se adaugă (mod detaliat) și f pentru a specifica numele fișierului de ieșire (miprog-1.0.tar). Rezultatul este un fișier tar necomprimat pe care îl puteți distribui sau salva ca o copie de rezervă.

Creați un fișier tarball comprimat .tar.gz sau .tgz

În practică, este aproape întotdeauna de dorit ca fișierul tarball al codului să ocupe mai puțin spațiu. Pentru aceasta, se folosește gzip cu opțiunea -z a comenzii tar, astfel încât ambele procese (tar + compresie) să fie efectuate într-o singură comandă:

tar -cvzf miprog-1.0.tar.gz ~/proyectos/miprog-1.0

Aici, opțiunea „z” indică faptul că gzip ar trebui utilizat ca compresor. Fișierul generat poate fi denumit .tar.gz sau .tgz, deoarece sunt practic echivalente. Conținutul rămâne același, dar comprimat, fiind ideal pentru încărcarea pe un site de descărcare , atașarea la un e-mail sau publicarea ca „lansare” într-un depozit.

Creați un fișier tar comprimat .tar.bz2

Dacă aveți nevoie de o compresie mai agresivă (fișiere puțin mai mici cu prețul unui timp de comprimare și decomprimare mai lung), puteți utiliza bzip2 cu opțiunea -j :

tar -cvjf miprog-1.0.tar.bz2 ~/proyectos/miprog-1.0

Indicatorul j îi spune fișierului tar să utilizeze bzip2 . Este obișnuit să găsești variante de nume precum .tar.tbz sau .tar.tb2, dar ideea este identică: un fișier tar comprimat cu bzip2 și gata de distribuit.

Enumerați conținutul unui tarball

Înainte de a extrage sau atinge ceva, poate doriți să vedeți ce se află în interiorul fișierului tarball . Pentru asta este opțiunea „t” (pentru cuprins):

tar -tvf miprog-1.0.tar

Această comandă vă va oferi o listă detaliată cu căile fișierelor, permisiunile și marcajele temporale . Același model se aplică și pentru fișierele .tar.gz și .tar.bz2, deoarece tar detectează compresia pe baza opțiunilor zoj:

tar -tvf miprog-1.0.tar.gz
tar -tvf miprog-1.0.tar.bz2

Extragerea fișierelor dintr-un tarball

Pentru a decomprima și extrage conținutul în directorul curent, trebuie doar să schimbați c în x, restul păstrând la fel:

tar -xvf miprog-1.0.tar

Dacă doriți să specificați un anumit director în care să salvați fișierele, adăugați opțiunea -C urmată de calea de destinație. În acest fel, puteți păstra codul sursă sau copiile de rezervă organizate.

tar -xvf miprog-1.0.tar -C /home/utilizator/src/

Același lucru este valabil și pentru fișierele tar comprimate cu gzip sau bzip2, pur și simplu prin adăugarea opțiunii de compresie corespunzătoare, cum ar fi tar -xvzf file.tar.gz sau tar -xvjf file.tar.bz2.

Extrage fișiere specifice și folosește caractere wildcard

Unul dintre avantajele fișierului tar este că poți extrage doar anumite fișiere în loc să decomprimi întreaga arhivă. De exemplu, dacă în sampleArchive.tar există un script numit example.sh pe care vrei să îl recuperezi:

tar -xvf exempluArhivă.tar exemplu.sh

Aceeași abordare funcționează și pentru fișierele tar comprimate, adăugând `zoj` după cum este necesar . De asemenea, puteți utiliza opțiunea `--wildcards` pentru a extrage doar fișierele care corespund unui model, ceea ce este foarte util pentru lucruri precum extragerea doar a imaginilor .jpg.

tar -xvf sampleArchive.tar –wildcard-uri '*.jpg'

În cazul fișierelor .tar.gz sau .tar.bz2, comanda ar fi similară, schimbându-se în -zxvf sau -jxvf pentru a respecta metoda de compresie utilizată în fișierul original.

Creați un tarball de cod sursă de la zero

Dincolo de comprimarea folderelor individuale, utilizarea clasică a fișierelor tarball în lumea Unix este de a distribui codul sursă al unui program . Ideea este foarte simplă: autorul pregătește un director curat care conține proiectul, îl împachetează ca fișier tar.gz sau tar.bz2 și îl publică. Utilizatorii descarcă fișierul tarball, îl extrag și îl compilează local.

În multe cazuri, acel arbore de cod are un nume în stilul versiunii-programului , de exemplu hello-sh-1.0, astfel încât fișierul tar rezultat se numește hello-sh-1.0.tar.gz și, atunci când este decomprimat, este generat exact acel director cu tot ce este necesar în interior.

Un exemplu tipic pentru practică implică crearea unui mini-proiect cu un script simplu, acordarea permisiunilor de execuție și apoi împachetarea acestuia. De exemplu:

$ mkdir -p hello-sh/hello-sh-1.0; cd hello-sh/hello-sh-1.0
$ pisică > salut <
# / Bin / sh
# (C) 2011 Foo Bar, GPL2+
.echo „Salut!”
EOF
$ chmod 755 salut
$cd..
$ tar -cvzf salut-sh-1.0.tar.gz salut-sh-1.0

Cu această procedură ați generat o arhivă tar trivială cu cod sursă pe care ați putea apoi să o despachetați în orice distribuție de tip Unix și să rulați scriptul fără alte formalități.

Descărcați, dezarhivați și pregătiți codul sursă

Acum este o practică obișnuită ca autorul unui program software liber să își publice codul ca fișier tar.gz sau tar.bz2 pe site-ul său web sau pe platforme precum GitHub . Aceste fișiere conțin arborele codului sursă, documentația (README, INSTALL etc.) și adesea fișierele necesare pentru generarea Makefile-urilor și a scripturilor de compilare.

Dacă proiectul nu vine ca fișier tarball, ci dintr-un sistem de control al versiunilor (Git, Subversion, CVS…) , atunci va trebui să clonați repozitoriul cu `git clone`, `svn co` sau `cvs co` și apoi să împachetați directorul respectiv cu `tar`, de preferință folosind opțiunea `--exclude-vcs` pentru a evita includerea metadatelor sistemului de control al versiunilor.

tar -cvzf proiect-1.0.tar.gz –exclude-vcs proiect-1.0

Uneori, fișierul sursă vine comprimat în alte formate, cum ar fi .zip sau .Z . În acest caz, îl decomprimați cu instrumentele corespunzătoare și, dacă doriți să urmați standardul clasic de distribuție din GNU/Linux, îl reîmpachetați ca arhivă tar (tar.gz sau tar.bz2), păstrând structura versiunii programului.

Instalați instrumentele de compilare și citiți documentația

Înainte de a compila orice dintr-o arhivă tarball, este recomandabil să vă asigurați că sistemul dumneavoastră are instrumentele de dezvoltare de bază . Pe Debian, Ubuntu și derivate, acest lucru este de obicei la fel de simplu ca instalarea metapachetului build-essential:

sudo apt install build-essential

Alte distribuții au nume diferite, dar ideea este aceeași: pe Fedora/Red Hat poți folosi ` sudo dnf groupinstall "Development Tools"` , iar pe Arch Linux folosești `sudo pacman -S base-devel` . Important este să ai un compilator (gcc, g++), un make și antete standard.

După ce ați extras fișierul tarball, primul lucru de făcut este să navigați la directorul proiectului și să citiți cu atenție fișierele README și INSTALL , deoarece acestea explică de obicei metoda de compilare, dependențele și orice alte detalii specifice. Puteți folosi less, cat sau editorul de text preferat pentru asta.

Compilarea codului sursă dintr-un fișier tarball: metoda clasică

Majoritatea proiectelor simple distribuite ca arhive tar includ un Makefile (puteți învăța cum să creați și să stăpâniți Makefile-uri ) sau un sistem de compilare bazat pe Autotools. În aceste cazuri, fluxul de lucru tipic constă în trei pași: configurare, compilare și instalare, cu unele variații în funcție de proiect.

În multe cazuri, după extragerea fișierului tarball, trebuie doar să rulați ceva de genul ` ./configure && make && sudo make install` în directorul rădăcină al codului . Cu toate acestea, există câteva detalii interesante mai jos care merită știute pentru a nu intra în orb.

Autotools: configurare, Makefile și companie

Multe programe software gratuite folosesc GNU Autotools (Autoconf, Automake, Libtool, gettext etc.) pentru a genera fișiere Makefile portabile pentru diverse platforme. Dacă vedeți fișiere precum configure.ac, Makefile.am sau Makefile.in în arborele sursă, este aproape sigur că proiectul se bazează pe acest sistem.

Autorul rulează de obicei `autorecof -i -f` în mediul său pentru a genera scriptul `configure` și fișierele `Makefile.in` corespunzătoare din aceste fișiere sursă. Apoi, pe mașina dvs., ar trebui să rulați `./configure`, care ar crea fișierele Makefile finale adaptate sistemului dvs. (detectând bibliotecile, căile, compilatorul etc.).

Fluxul de lucru simplificat ar fi cam așa: fișierele configure și Makefile.in sunt construite din configure.ac și Makefile.am, iar apoi, prin rularea comenzii ./configure, se generează Makefile și config.h. În final, o comandă simplă `make` compilează fișierul binar. Dacă trebuie să ajustați directoarele de instalare, puteți transmite opțiuni scriptului configure, de exemplu , `./configure --prefix=/usr` pentru a schimba prefixul implicit de instalare.

Compilarea cu CMake ca alternativă modernă

Un alt sistem de compilare utilizat pe scară largă în zilele noastre este CMake . Îl veți recunoaște după prezența fișierului CMakeLists.txt în rădăcina proiectului. Modelul de compilare dintr-un fișier tarball implică de obicei crearea unui director de compilare separat, generarea configurației acolo și compilarea în cadrul acestuia.

mkdir build
CD build
face ..
face
sudo face instalare

Această abordare menține arborele sursă mai curat și vă permite să generați proiecte pentru diferite platforme sau IDE-uri folosind aceleași fișiere CMakeLists.txt. Logica, însă, rămâne aceeași ca în cazul Autotools: configurare, compilare și instalare.

Rezolvarea erorilor de dependență la configurare

Este destul de frecvent ca prima trecere a comenzii `./configure` să eșueze deoarece lipsește o bibliotecă, un antet sau o dependență de dezvoltare. Scriptul afișează de obicei un mesaj clar precum „libejemplo not found” sau „cannot find header xyz.h”.

În multe distribuții, bibliotecile sunt împachetate în trei variante: binare, bibliotecă și bibliotecă de dezvoltare . Urmând modelul exemplu, este posibil să aveți pachete numite example, libexample și libexample-dev. Pentru a compila din arhiva tar, aveți nevoie de obicei de varianta -dev (aceasta include anteturile și fișierele necesare pentru linkare), așa că, dacă întâmpinați o eroare cu libexample, soluția practică este de obicei să instalați libexample-dev și să încercați din nou.

Este posibil ca după instalarea unui `-dev` să rulați din nou `configure` și acesta să se plângă de o bibliotecă diferită. Este în regulă: este un proces de încercare și eroare până când îndepliniți toate dependențele . După ce ați făcut acest lucru, `configure` se va finaliza cu succes și puteți continua compilarea.

Compilează cu make și instalează cu make install

Odată ce pasul de configurare a decurs bine, puteți rula comanda `make` pentru a compila proiectul. În funcție de dimensiunea programului și de puterea de procesare a mașinii dvs., acest proces poate dura de la câteva secunde la câteva minute. Veți vedea comenzile de compilare și conectare executate afișate în terminal .

Dacă totul merge corect și nu apar erori de compilare, singurul pas rămas este instalarea rezultatului pe sistem cu `sudo make install` . Prin convenție, multe proiecte sunt instalate sub `/usr/local` (binarele în `/usr/local/bin`, bibliotecile în `/usr/local/lib`, configurațiile în `/usr/local/etc…`), astfel încât să nu fie amestecate cu propriile pachete ale distribuției.

Unele proiecte implementează și obiectivul `make uninstall` , care vă permite să anulați instalarea și să ștergeți fișierele copiate cu `make install`. Nu toate proiectele îl includ, dar dacă este listat în documentație, este o modalitate relativ convenabilă de a dezinstala ceea ce ați compilat din arhiva tarball.

Când și cum se creează un fișier tarball pentru împachetarea pachetelor în Debian

În lumea Debian și derivatele sale, fișierul tarball al codului original este de obicei numit version_name.orig.tar.gz . Ideea este de a separa clar codul sursă „în amonte” de modificările specifice Debian (patch-uri, fișiere de control, scripturi post-instalare etc.) care sunt adăugate în directorul debian al pachetului sursă.

Dacă dezvoltatorul inițial a denumit fișierul tar gentoo-0.9.12.tar.gz, de exemplu, ca responsabil Debian, îl puteți redenumi în gentoo_0.9.12.orig.tar.gz și puteți lucra de acolo. Apoi veți adăuga subdirectorul debian la această sursă, care conține toate fișierele necesare pentru a construi pachetele .deb.

Instrumentul dh_make simplifică foarte mult această sarcină: începând cu gentoo-0.9.12.tar.gz, decomprimă codul sursă, generează fișierul tar .orig corespunzător și creează șabloane în debian/ pe care le puteți apoi ajusta. După rulare, veți vedea că directorul dvs. de lucru conține atât codul original redenumit, cât și arborele sursă, gata pentru împachetare.

Denumiți corect pachetul și versiunea în fișierele tar și pachete

Când se distribuie cod sursă ca arhivă tarball, este esențial ca numele fișierului și directorul intern să respecte o convenție consecventă . În ecosistemul Debian, de exemplu, se recomandă ca numele pachetului să utilizeze doar litere mici, cifre, semne plus și minus și puncte, cu o lungime rezonabilă și începând întotdeauna cu un caracter alfanumeric.

Numărul versiunii, la rândul său, ar trebui să conțină doar caractere alfanumerice, semne plus (+), tilde (~) și puncte ( .), începând întotdeauna cu o cifră. Acest lucru facilitează compararea corectă a versiunilor de către instrumente precum dpkg. Dacă autorul programului folosește șiruri de caractere neobișnuite (date cu text, hash-uri Git etc.), puteți salva aceste informații în jurnalul de modificări Debian, dar este recomandat să păstrați câmpul „upstream version” din fișierul tarball curat și organizat.

În cazul versiunilor prerelease sau release candidate, de obicei se introduce o tildă (~) pentru ca dpkg să interpreteze corect ordinea . De exemplu, dacă aveți o versiune prerelease gentoo-0.9.12-ReleaseCandidate-99.tar.gz, o puteți redenumi în gentoo-0.9.12~rc99.tar.gz, astfel încât 0.9.12 să fie considerată mai mare decât 0.9.12~rc99 atunci când este lansată versiunea finală.

Din fișierul tarball la pachetul binar: pachet ca .deb

Un fișier tarball de cod este doar primul pas dacă scopul tău este să distribui programul ca un pachet .deb instalabil (vezi instalatoarele populare de pachete software ). Din fișierul tar.gz original, poți crea structura necesară pentru a genera un pachet .deb, poți adăuga fișierul binar compilat și metadatele și poți construi pachetul folosind dpkg-deb.

În interior, un fișier .deb conține practic trei părți: debian-binary (un fișier text minimal cu versiunea formatată), control.tar.gz (metadate și scripturi de control) și data.tar.gz (binarele și fișierele care vor fi instalate). Puteți utiliza utilitarul `ar` pentru a inspecta un fișier .deb și a vedea exact aceste componente.

Pentru a împacheta ceva foarte simplu, cum ar fi un program „hello world” în C, ai putea mai întâi compila fișierul binar din codul sursă din fișierul tarball și apoi să configurezi manual structura de directoare .deb . Ai crea un director numit hello/, în interiorul său un subdirector numit DEBIAN care conține fișierul de control, apoi ai copia executabilul în calea corespunzătoare (de exemplu, hello/usr/bin/). După aceea, ai rula pur și simplu ` dpkg-deb --build hello` pentru a genera fișierul hello.deb.

De la tarball la pachet RPM și alte formate

Ceva foarte similar se întâmplă în lumea Red Hat cu pachetele RPM . Codul sursă este de obicei distribuit în fișiere tar, iar de acolo sunt generate SRPM-uri (pachete sursă RPM) care conțin atât fișierul tar original, cât și unul sau mai multe patch-uri și fișierul .spec care descrie cum se compilează și se instalează programul.

În acest caz, structura directoarelor de lucru include căi precum RPMS, SRPMS, SOURCES, SPECS etc. Fișierul tar original merge în SOURCES, fișierul .spec în SPECS, iar de acolo puteți utiliza rpmbuild pentru a genera fișierul binar .rpm și, dacă doriți, fișierul .src.rpm. Fișierul .spec conține informații precum numele pachetului, versiunea, dependențele, comenzile de compilare și lista de fișiere care ar trebui să ajungă în sistem.

Rezultatul final este foarte similar cu un fișier .deb: un pachet binar pe care utilizatorul îl poate instala cu managerul său de pachete obișnuit, dar a cărui rădăcină este de obicei un tarball de cod sursă organizat și bine versionat.

Creați fișiere tarball și împachetați-le în formate universale

În ultimii ani, au apărut formate precum Snap, Flatpak și AppImage , care au ca scop oferirea de pachete „universale” pentru Linux și reducerea fragmentării dintre distribuții. Deși fiecare are propriile mecanisme, toate se pot baza pe un arbore de cod pe care l-ați putea distribui și ca arhivă tar.

În Snap, de exemplu, definiți în fișierul snapcraft.yaml modul în care este construită aplicația dvs.: numele, versiunea, sursa (care poate fi o adresă URL către un tarball la distanță), pluginurile de compilare (autotools, cmake etc.) și comanda finală de executat. Snapcraft va descărca apoi tarball-ul, îl va compila și îl va împacheta împreună cu dependențele sale.

Flatpak funcționează cu un manifest JSON sau YAML care descrie runtime-ul, SDK-ul și modulele care urmează să fie construite, specificând și sursa (care poate fi un fișier local sau o arhivă tar la distanță). Din nou, arhiva tar este containerul natural pentru codul sursă care va fi integrat ulterior în pachetul universal.

În AppImage, deși pornești adesea de la fișiere binare precompilate, poți ajunge acolo și dintr-un arbore de cod clasic: compilezi din arhiva tar, generezi structura AppDir și, în final, creezi imaginea autoexecutabilă pe care utilizatorul o poate lansa fără o instalare corespunzătoare.

Tarball-uri, compresie directă și alte utilizări practice

Pe lângă împachetarea codului, tar este utilizat pe scară largă pentru comprimarea și decomprimarea datelor generale : directoare de configurare, foldere personale, copii de rezervă ocazionale etc. Pe sistemele de tip Unix, inclusiv multe versiuni de Android și macOS, tar este adesea inclus în mod implicit și oferă un raport de compresie foarte rezonabil, aproape de 50% în multe cazuri, cu o viteză de operare destul de mare.

Dar fiți atenți, există nuanțe: instrumente precum gzip sau bzip2 comprimă doar fișiere, nu directoare . Când rulați `tar -czf` sau `tar -cjf`, tar grupează mai întâi directoarele și apoi transmite rezultatul către gzip sau bzip2. De aceea este atât de practic să folosiți tar ca „frontend” pentru aceste utilitare.

Dacă vrei să verifici rapid dimensiunea unui fișier tar sau să măsori impactul compresiei, poți lega `tar` cu `wc -c` pentru a număra octeții, folosind o cratimă ca ieșire standard. De exemplu:

tar -czf – sampleArchive.tar | wc -c

Acest truc facilitează obținerea unei idei despre câtă greutate economisești prin împachetarea unui anumit director, ceea ce este foarte util atunci când pregătești distribuții de cod sau copii de rezervă pe care le vei muta prin rețea.

După cum puteți vedea, stăpânirea utilizării fișierelor tar pentru a împacheta și distribui cod pas cu pas deschide multe uși: de la crearea unor copii simple comprimate ale proiectelor dvs. până la pregătirea unui cod sursă curat pentru împachetare în formate .deb, .rpm sau universale; toate acestea menținând permisiunile, structura directoarelor și practicile bune de versionare care vă vor face viața (și pe cea a celor care utilizează software-ul dvs.) mult mai ușoară.