Translation(s): English - Italian - Català



Introducció al empaquetament de Debian

Sessió de formació a l'IRC de Debian Women per Lars Wirzenius, 18-Nov-2010

Aquest tutorial es una introducció per a la creació de paquets Debian: no s'aprofunditza molt en la creació de paquets Debian, però s'ensenya com fer-los per a programari fàcil d'empaquetar.

Per aquest propòsit, es farà servir només l'ordre dh de debhelper 7.

Requeriments

En aquest tutorial s'assumeix que:

Requeriments tècnics:

Els tres conceptes centrals

Els tres conceptes centrals són el el paquet tar d'upstream, el paquet de codi font, i el paquet binari. La majoria de la gent empaqueta programari que algú altre a desenvolupat: el desenvolupador en aquest cas s'anomena desenvolupador upstream. El desenvolupador d'upstream alliberarà una versió del seu programari, i el resultat d'aquest alliberament serà el "el arxivador del codi font d'upstream " o paquet tar.

Un paquet tar es un fitxer amb extensió .tar.gz o .tgz que crea el desenvolupador d'upstream (el paquet tarball es argot informàtic). El paquet tar es d'on es crea el paquet Debian. Quan es disposa de un paquet tar d'upstream, el següent pas és crear el paquet Debian de codi font, des del que es pot construir el paquet Debian binari, que es el que s'instal·la.

El paquet de codi font consisteix, en la forma més simple, d'aquests tres fitxers:

  1. El paquet tar d'upstream, renombrat per a seguir un patró sistemàtic.
  2. Un pedaç (fitxer patch), que contingui tots els canvis realitzats al codi font d'upstream, més els fitxers creats per al paquet Debian. L'extensió d'aquest fitxer és .diff.gz.

  3. Un fitxer de descripció (amb extensió .dsc), que llista els altres altres dos fitxers.

A primera vista això sembla una mica més complicat del necessari: Es més simple tenir-ho tot en un únic fitxer. Però mantenint el paquet tar d'upstream separat de qualsevol canvi especific de Debian s'aconsegueix un gran estalvi d'espai en disc i d'ample de banda. També permet veure quins canvis s'han tingut que realitzar per a Debian.

Els passos del procés d'empaquetatge

Els passos del procés d'empaquetatge solen ser semblants a :

  1. renombrar el paquet tar d'upstream per a seguir un patró específic

  2. descomprimir el paquet tar d'upstream

  3. afegir els fitxers del paquet Debian (en un subdirectori anomenat debian), i realitzar altres canvis necessaris.
  4. construir el paquet de codi font
  5. construir el paquet binari
  6. pujar els paquets de codi font i binari a Debian

Per a aquest tutorial Lars va fer servir aquest paquet tar.

Pas 1: renombrar el nom del paquet tar

Les eines d'empaquetat de Debian assumeixen que el paquet tar d'upstream té un nom específic.

El nom consisteix en el nom del paquet de codi font, un guió baix, el número de versió d'upstream, seguit de .orig.tar.gz. El paquet de codi font s'ha d'anomenar sense majúscules, i pot contenir lletres, dígits, i guions. Altres caràcters també estan permesos.

Si el desenvolupador d'upstream fa servir un nom que sembla un bon nom per a un pquet Debian de codi font, has de fer-lo servir. Si no és així, canvia el nom del paquet d'upstream el mínim possible per a que coincideixi amb els criteris de Debian. En aquest cas, el nom del paquet d'upstream és correcte, així que no hi ha res pel que preocupar-se.

Hem d'acabar amb un fitxer anomenat hithere_1.0.orig.tar.gz.

Noteu que hi ha un guió baix i no un guió en el nom del fitxer. Això es important, perquè les eines d'empaquetatge són exigents.

# mv hithere-1.0.tar.gz hithere_1.0.orig.tar.gz

Pas 2: descomprimir el paquet tar

Hem de tenir un directori anomenat "hithere-1.0". En general, el codi font anirà dins d'un directori anomenat després del nom del paquet de codi font i la versió d'upstream, amb un guió en mig.

Això es perquè, un altre cop, les eines d'empaquetatge són exigents.

En aquest cas, el paquet d'upstream coincideix amb els criteris de Debian, i el paquet tar del codi font és troba ja en el subdirectori correcte.

 # tar xf hithere_1.0.orig.tar.gz

Pas 3: afegir els fitxers del paquet Debian

Tots aquests fitxers han d'anar dins del subdirectori debian/ dins de l'arbre.

# cd hithere-1.0
# mkdir debian

Hi ha una sèrie de fitxers que hem de proporcionar. Anem a veure'ls en ordre.

debian/changelog

El primer fitxer és debian/changelog. Aquest fitxer és un històric dels canvis realitzats al paquet Debian.

No es necessari que contingui tot el que s'ha canviat al codi font d'upstream, però això també pot ser útil als usuaris per a conèixer aquests canvis. Com que estem fent la primera versió, no hi ha cap històric. Però hem de fer una entrada a l'històric, perquè les eines de empaquetament llegeixen certa informació del històric de canvis. El més important, llegeixen la versió del paquet.

El fitxer debian/changelog té un format molt particular. La forma més fàcil de crear-lo és fer servir l'eina dch.

# dch --create -v 1.0-1 --package hithere

Això crearà un fitxer semblant a aquest:

hithere (1.0-1) UNRELEASED; urgency=low

  * Initial release. (Closes: #XXXXXX)

 -- Lars Wirzenius <liw@liw.fi>  Thu, 18 Nov 2010 17:25:32 +0000

Unes quantes notes:

debian/compat

Aquest fitxer ha de contenir el número 7. Aquest és un número màgic. No s'ha de canviar per cap altre. El fitxer debian/compat especifica el "nivell de compatibilitat" per a l'eina debhelper . Aquí no s'explicarà que significa això.

debian/control

El fitxer de control conté una descripció dels paquets de codi font i binari, i dóna alguna informació d'ells, com els seus noms, qui manté el paquet, i així successivament. A continuació hi ha un exemple de com tindria que quedar el fitxer.

Source: hithere
Maintainer: Lars Wirzenius <liw@liw.fi>
Section: misc
Priority: optional
Standards-Version: 3.9.0
Build-Depends: debhelper (>= 7.3.8)

Package: hithere
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: greet user
 hithere greets the user, or the world.

Hi ha algunes caselles requerides, però de moment no s'expliquen. Al fitxer debian/control, hi han dos paràgrafs.

El primer paràgraf descriu el paquet de codi font:

"Source:"
casella que indica el nom del paquet de codi font.
"Maintainer:"
casella que indica el nom i el correu electrònic de la persona responsable d'aquest paquet.
"Build-Depends:"
indica quins paquets han d'estar instal·lats per a poder construir el paquet. Poden o no ser necessaris per a l'us del paquet.

El segon paràgraf descriu el paquet binari construir des del codi font. Actualment poden haver-hi varis paquets binaris construirs des del mateix codi font.

"Package:"
és el nom del paquet binari. El nom pot ser diferent que el del paquet de codi font.
"Architecture:"
indica en quines arquitectures de processador s'espera que funcioni el paquet binari: i386 per a CPUs Intel de 32-bit , amd64 per a CPUs de 64-bit, armel per a processadors ARM, etc. Debian funciona en una dotzena de arquitectures en total , així que el suport per a arquitectures es crucial. La casella "Architecture:" pot contenir noms de arquitectures particulars, però sol contenir un dels dos valors especials.
"any"
(com el que podem veure en el exemple) significa que el paquet pot ser construït per a qualsevol arquitectura. En altres paraules, el codi s'ha escrit de manera que sigui portable, així no s'han de fer suposicions sobre el maquinari. Però el paquet binari s'haurà de construir per a cada arquitectura de manera separada.
"all"
significa que el mateix paquet binari pot funcionar a totes les arquitectures, sense haver de construir per a cada arquitectura. Per exemple, un paquet que contingui només scripts shell serà "all". Els scripts Shell funcionen igual en qualsevol lloc i no necessiten ser compilats.
"Depends:"

En aquesta casella s'indiquen els paquets que han d'estar instal·lats per a que el programa del paquet binari pugui funcionar. Llistar aquestes dependències manualment pot és tediós, i és propens a error. Per a fer aquesta tasca, és necessari posar el valor "màgic" ${shlibs:Depends}. Les altres coses "màgiques" són per a debhelper. També hi ha el valor "màgic" {misc:Depends}. El valor shlibs es per a les dependències de llibreries compartides, el valor misc és per a altres coses que fa debhelper per a altres dependències, és necessari que ho afegeixis manualment a Depends o Build-Depends i que afegeixis la part: ${...}. Els valors "màgics" només funcionen a Depends.

"Description:"
és la descripció del paquet. Es significativa per a ser útil als usuaris.

debian/copyright

Aquest fitxer es important, però de moment el deixarem en blanc.

Per a Debian, aquest fitxer és usat per a seguir la informació legal relacionada amb el copyright d'aquest paquet. Però, no és important d'es del punt de vista tècnic. Per ara, és concretarà en els aspectes tècnics.

debian/rules

Aquest fitxer ha de ser similar a:

#!/usr/bin/make -f
%:
        dh $@

El fitxer debian/rules pot ser un fitxer una mica complicat. Però l'ordre dh a la versió 7 de debhelper fa possible que sigui fàcil en molts casos.

debian/source/format

L'últim fitxer que necessitem és el fitxer debian/source/format, i ha de contenir el número de la versió "1.0".

Aquest es el número de la versió del paquet font, i resulta que és el mateix que la versió d'upstream, això només es una coincidència.

Passos 4 i 5: construir el paquet

Ara es pot construir el paquet. L'ordre per a fer-hi és

debuild -us -uc

Hi han varies ordres que podem fer servir per a fer això, però aquesta es la que farem servir. A l'executar l'ordre, obtindràs una sortida similar a aquesta:

make[1]: Entering directory `/home/liw/debian-packaging-tutorial/x/hithere-1.0'
install hithere /home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere/usr/local/bin
install: cannot create regular file `/home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere/usr/local/bin': No such file or directory
make[1]: *** [install] Error 1
make[1]: Leaving directory `/home/liw/debian-packaging-tutorial/x/hithere-1.0'
dh_auto_install: make -j1 install DESTDIR=/home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere returned exit code 2
make: *** [binary] Error 29
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
debuild: fatal error at line 1325:
dpkg-buildpackage -rfakeroot -D -us -uc failed

Alguna cosa ha sortit malament. Això acostuma a passar. Els fitxers dins de debian/* s'han creat bé, però sempre hi ha alguna cosa que no es fa bé. El que està fallant es el següent:

install hithere /home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere/usr/local/bin

El fitxer Makefile d'upstream està intentant instl·lar el programa compilat a l'ubicació incorrecte.

Hi han unes quantes coses que estan passant: primer es una mica com funcionen els paquets Debian.

Quan un programa és construeix, i s'instal·la, no s'instal·la a /usr o /usr/local, com de costum, sinó a algún lloc dins del subdirectori debian/.

Creem una part de tot el sistema de fitxers dins de debian/hithere, i després posem això dins del paquet binari. Així que .../debian/hithere/usr/local/bin és correcte, excepte per que no s'ha d'instal·lar a usr/local, sinó que directament a usr.

És necessari fer algunes coses per a que s'instal·li en l'ubicació correcte: (debian/hithere/usr/bin).

La manera correcta d'arreglar això es canviar el fitxer debian/rules per a que indiqui a l'ordre Makefile on s'han d'instal·lar aquestes fitxers.

#!/usr/bin/make -f
%:
        dh $@

override_dh_auto_install:
        $(MAKE) DESTDIR=$$(pwd)/debian/hithere prefix=/usr install

Per a entendre això és necessari entendre com funcionen els Makefiles, i com s'executen les diferents etapes de debhelper.

Per ara, es pot resumir que dient que hi ha una ordre que debhelper executa que s'ocupa d'instal·lar els fitxers d'upstream, aquesta etapa s'anomena dh_auto_install.

És necessari anular aquesta etapa, ho fem amb una regla al fitxer debian/rules anomenada override_dh_auto_install.

L'última línia del fitxer debian/rules invoca l'ordre Makefile des del fitxer debian/rules amb els arguments correctes.

Intentem construir el paquet un altre vegada. Segueix fallant!

install hithere /home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere/usr/bin

Ara estem intentant instal·lar-ho a l'ubicació correcte, però no existeix. Per a solucionar això, necessitem que les eines d'empaquetatge creïn el directori primer.

La manera ideal, seria que el Makefile d'upstream creï el directori, però en aquest cas el desenvolupador d'upstream no ho va indicar al fitxer Makefile.

Les eines d'empaquetatge (específicament, debhelper) proporcionen una manera de fer-ho.

usr/bin
usr/share/man/man1

La segona línia crea el directori per a la pàgina del manual. ho necessitarem més endevant. Ara la construcció es realitza correctament, però encara hi han alguns petits problemes.

l'ordre debuild executa l'eina lintian, que comprova alguns errors comuns al construir el paquet. Reporta alguns per al nou paquet:

Now running lintian...
W: hithere source: out-of-date-standards-version 3.9.0 (current is 3.9.1)
W: hithere: copyright-without-copyright-notice
W: hithere: new-package-should-close-itp-bug
W: hithere: wrong-bug-number-in-closes l3:#XXXXXX
Finished running lintian.

Aquests errors s'haurien de corregir, però no sembla que ningun d'ells doni problemes per a provar el paquet. Així que de moment ignorem els errors.

Mirem en el directori pare per a trobar el paquet que s'ha construït.

 # ls ..

hithere-1.0                  hithere_1.0-1_amd64.deb  hithere_1.0.orig.tar.gz
hithere_1.0-1_amd64.build    hithere_1.0-1.diff.gz
hithere_1.0-1_amd64.changes  hithere_1.0-1.dsc

La següent ordre instal·larà el paquet que acabem de construir. No executis l'ordre en ordinador que no vulguis espatllar.

Les màquines virtuals són un bon lloc on construir paquets.

# sudo dpkg -i ../hithere_1.0-1_amd64.deb

Que mostrarà la següent sortida:

liw@havelock$ sudo dpkg -i ../hithere_1.0-1_amd64.deb
[sudo] password for liw: 
Selecting previously deselected package hithere.
(Reading database ... 154793 files and directories currently installed.)
Unpacking hithere (from ../hithere_1.0-1_amd64.deb) ...
Setting up hithere (1.0-1) ...
Processing triggers for man-db ...
liw@havelock$ 

Com comprovem el paquet? Podem executar la seva ordre.

# hithere

Funciona! Però, no es perfecte. L'ordre lintian detectava alguns errors, el fitxer debian/copyright està buit, etc.

Tenim un paquet que funciona, però que encara no té la qualitat que s'espera d'un paquet Debian.

Conclusions

Un cop hagis construir els teus propis paquets, voldràs aprendre com configurar el teu propi dipòsit apt, per a que el teu paquet sigui fàcil d'instal·lar. La millor eina que conec per a això és reprepro.

Per a provar més el teu paquet, pots mirar l'eina anomenada piuparts.

I, finalment, si vols començar a fer canvis a la font d'upstream, tindràs que aprendre l'eina quilt.

Altres coses que potser vulguis llegir estan disponibles a la pàgina http://www.debian.org/devel/.

Preguntes i respostes

PREGUNTA: Es pot generar un paquet Debian per a vàries arquitectures?

RESPOSTA: De moment Debian no suporta paquets de vàries arquitecutres, però si que suporta paquets per a totes les arquitectures.

PREGUNTA: Per favor, aclara que s'ha de fer amb els paquets que ja estan en forma binaria, com per exemple l'Nvidia blob o semblants.

RESPOSTA: Per als paquets binaris amb blobs, tractes el paquet binari que conté els blobs com el paquet del codi font, i simplement evites el pas de la compilació del codi font.

PREGUNTA: Hi ha alguna cosa semblant als PPA d'Ubuntu?

RESPOSTA: Debian no ofereix un servei PPA com Ubuntu, però totes les eines per a crear dipòsits apt estan disponibles per a que tu puguis crear-ne un, només que has de configurar-lo tu mateix.

PREGUNTA: Es necessari tornar a empaquetar el paquet original si aquest no conté una carpeta foo-1.0 correctament anomenada?

RESPOSTA: Actualment no es necessari tornar-lo a empaquetar. Era necessari anys enrere, però ara la nova ordre "dpkg-source -x" renombrarà el directori correctament, en cas de que sigués neccessari.

PREGUNTA: Es poden observar paquets Debian "oficials" a /var/cache/apt/archives sense els fitxers changelog i compat. Perquè?

RESPOSTA: Els fitxers .deb que hi ha a /var/cache/apt/archives són paquets binaris; el fitxer changelog està inclòs en ells (però amb un nom diferent), el fitxer compat només es troba als paquets de codi font.

PREGUNTA: Liw va dir que el fitxer compat ha de tenir el número 7, s'ha d'assumir que això significa que ha de ser un únic número produit per l'execució de la ordre 'echo 7 >debian/compat'?

RESPOSTA: Sí, un únic caràcter 7 es suficient per a tenir al fitxer debian/compat

PREGUNTA: He sentit que hi ha un format específic dels números de revisió per als paquets no mantinguts.

RESPOSTA: Crec que et refereixes o als paquets natius (en els que el número de versió serà 1.0, i no 1.0-1); o al format de paquets penjats "non-mantainer", en aquest cas és una explicació molt detallada per a explicar quina seria la manera correcta en tots els casos, però "1.0-1.1" seria un exemple

PREGUNTA: En quin moment s'executa l'ordre "dpkg-source -x"? S'ha d'executar manualment?

RESPOSTA: L'ordre "dpkg-source -x" serveix per a desempaquetar un paquet de codi font de Debian després de que s'hagi creat; no s'acostuma a executar en el procés de creació d'un paquet.

PREGUNTA: Com es pot determinar quins son els paquets a fer servir per Build-Depends?

RESPOSTA: Jo ho acostumo a fer mitjançant: a) Prova i error i b) llegint el codi font del programa, els dos casos solen ser necessaris.

PREGUNTA: Puc construir un paquet per a armel des del meu equip i386 facilment?

RESPOSTA: Això seria fent servir compilació creuada, i no crec que hi hagi una manera fàcil per a fer-ho. Hi han eines per a fer-ho, però no sóc familiar amb elles.

PREGUNTA: Quina és la diferencia entre dependències i dependències de construcció, en quin cas haig de fer servir només les dependències en comptes de les dependències de construcció?

RESPOSTA: Les dependències de construcció només són necessàries durant el procés de construcció del paquet, una vegada s'ha compilat i quan la suite de testeig s'està executant. Les dependències només són necessàries quan el paquet s'esta fent servir, després de ser instal·lat. En alguns casos hi han coses que són dependències i dependències de construcció, en aquests casos, has de posar-les com dependències de construcció i com a dependències.

Per exemple, si un paquet conté un script PHP, però que no s'executa quan s'està construint el paquet, PHP serà només dependència, i no serà dependència de construcció.

Però, si l'script PHP només executa una prova, però no s'inclou en el paquet binari, PHP serà una dependència de construcció, i no serà una dependència.

PREGUNTA: Poden haver-hi dependències de construcció que no tinguin les corresponents dependències? Pensant a les llibreries estàtiques enllaçades.

RESPOSTA: Les dependències de construcció i les dependències estan molt separades, i és correcte (des del punt de vista de la eina de construcció de paquets) tenir dependències només en un lloc i no en l'altre, o en els dos.

PREGUNTA: Si vols fer pujar un paquet no mantingut, has d'escriure el teu nom a la casella del penjador del paquet, a la casella del mantenidor del paquet, o a ninguna casella?

RESPOSTA: (per dapal) ninguna, però la primera línia del fitxer changelog té que ser "Non-mantainer upload"

PREGUNTA: Quan es construeix un paquet amb la casella "Arquitecture: all", alguns dels fitxers (b.build .changes) segueixen tenint la arquitectura de construcció en el nom. Es això correcte?

RESPOSTA: Sí, es correcte, no hi ha perquè preocupar-se.

PREGUNTA: Hi ha un altre paquet per al paquet de codi font o es el mateix que el paquet binari? S'han de construir i mantenir els dos paquets (el binari i el de codi font)?

RESPOSTA: Tu edites el paquet de codi font i després executes una ordre que construeix el paquet binari des del paquet de codi font.

PREGUNTA: No tinc clar si les opcions "d'arquitectura" tindran efecte sobre el paquet de codi font (al procés de construcció) o sobre el paquet binari (a la instal·lació i execució).

RESPOSTA: La casella "d'arquitectura" indica a qualsevol persona que vulgui construir el paquet en una arquitectura de processador concreta, que si el paquet es per a i386 no hi ha possibilitat de construir-lo en amd64.

PREGUNTA: En aquest exemple el fitxer debian/rules només conté #!make -f , què s'ha de fer amb ./configure , cmake, scons o .. algun altre ordre semblant?

RESPOSTA: dh és molt heurístic, per tant un paquet amb un scrpit ./configure , o una de les maneres típiques de construir paquets, es tindria que construir sense afegir-hi res

PREGUNTA: l'heurística es bona, però que passa si es necessita passar --algo-especial per a configurar arguments de cmake, l'heurística configura els paquets font que necessiten executar l'eina ./waf o altres eines per a construir-lo?

RESPOSTA: La resposta de depal es correcta: <dapal> lilith: fent servir dh7, si necessites passar algo a ./configure, només has de escriure algo semblant a: override_dh_auto_configure <TAB>dh_auto_configure -- --els-paràmetres dh té un excelent mecanisme d'extensions/anualcions que et permet anual certes parts, es molt fàcil de fer servir, un cop t'has llegit el manual.

PREGUNTA: on es poden trobar els documents per a anular coses per a debhelper7?

RESPOSTA: dh executa una seqüencia específica d'ordres per a construir un paquet; cada ordre es anomenat dh_algo, i cada ordre pot ser anul·lada afegint una entrada al fitxer debian/rules anomenada override_dh_algo.

Afegeix la opció --no-act a la ordre dh en al fitxer debian/rules per a veure quines ordres executa; has de llegir la pàgina del manual per a aquesta ordre per a comprovar si pots configurar-ho (mitjançant un fitxer com debian/hithere.dirs), o si ho necessites, anul·la-ho.

PREGUNTA: des d'on executeu les ordres? des de dins del directori hithere-1.0 o des de fora? Ha d'haver-hi un directori anterior anomenat hithere (sense número)?

RESPOSTA: Jo sempre executo les ordres d'empaquetament dins del directori the hithere-1.0, i en general tinc un directori per sobre anomenat hithere però que realment no és necessari, és per a tenir-ho tot més endreçat i que no es mesclin els fitxers de diferents projectes.

PREGUNTA: Tinc un upstream que necessita fer servir l'eina qmake (fa servir Qt) abans de make. Puc afegir-ho al fitxer debian/rules? Com?

RESPOSTA: (per gregoa) l'eina debhelper suporta qmake des de la versió 7.4.12 (així que no es necessita afegir-hi res). Abans d'aquesta versió era necessari afegir override_dh_auto_configure :\n\tqmake

PREGUNTA: Quin seria un bon procés per a actualitzar un paquet a una nova versió d'upstream?

RESPOSTA: No ho conec amb seguretat, però bàsicament: descomprimir la font d'upstream a un nou directori, copiar el directori debian/* des de l'altre paquet, actualitzar el fitxer debian/changelog ("dch -v 1.2.3-4") i intentar construir-lo, i arreglar qualsevol cosa que s'espatlli. Aquest no és un bon procés, però per això tindrás que apendre quilt, i possiblement com administrar les versions amb els paquets Debian, i això es un tema molt gran per a aquesta sessió.

PREGUNTA: He fet un paquet Debian que depèn d'alguns paquets. L'única cosa que fa el meu paquet actualment és configurar els altres paquets per a que compleixin les necessitats d'algunes persones. Per això fa alguns canvis crítics al sistema, com activar l'enrutat en el nucli i altres coses... Hi ha alguna norma que indiqui que pot o no pot fer un paquet oficial? Pot obtenir un paquet oficial? RESPOSTA: El millor conjunt de normes que indiquen que pot fer o que té que fer un paquet oficial de Debian és pot trobar a: http://www.debian.org/doc/debian-policy/ No esta permès que un paquet de Debian canviï la configuració d'un altre paquet de Debian, a no ser que l'altre paquet inclogui una interfície documentada per a fer-ho.

Consulteu també