Capítol 2. Primers passos.

Sumari

2.1. Pla de treball de la construcció de paquets Debian
2.2. Seleccionar el programa.
2.3. Aconsegueix el programa i prova'l.
2.4. Sistemes de compilació simples
2.5. Sistemes de compilació populars
2.6. Nom del paquet i versió.
2.7. Configuració de quilt.
2.8. Paquet Debian no nadiu inicial.

Començarem la construcció del teu paquet (o encara millor, pots adoptar un paquet ja existent).

Si estàs treballant en la construcció d'un paquet Debian a partir de les fonts d'un programa, el pla de treball típic requereix la construcció d'arxius amb noms específics a cada una de les etapes de la següent manera.

Observa que el caràcter que separa nom_del_paquet i versió s'ha canviat de - (guió) a l'arxiu comprimit original a _ (guió baix) en el nom del paquet Debian.

En els noms del arxius anteriors, cal substituir nom_del_paquet pel nom del paquet, versió pel codi de versió del codi font, revisió pel codi de la revisió Debian i arquitectura per l'arquitectura del paquet com es defineix en el Manual de Normes de Debian [5].

Cada etapa d'aquest esquema s'explica amb detall en seccions posteriors.

Probablement ja tens clar quin paquet vols construir. Primer cal que comprovis si ja està inclòs en el repositori fent servir:

Si el paquet ja existeix, comença per instal·lar-ho. Si és un paquet orfe (si el responsable actual és el «Debian QA Group», el grup de qualitat de Debian), pots adoptar-lo (convertir-te en el responsable del manteniment) si està disponible. Cal que ho comprovis a «Debian Bug report logs»: errors en el paquet «wnpp» de la distribució de treball («inestable» o «sid»). També pots adoptar un paquet si hi ha un avís de «sol·licitud d'adopció» («Request for Adoption» o RFA) [6].

Hi ha diversos recursos de seguiment dels paquets:

Cal tenir present que Debian incorpora paquets d'un gran nombre de programes de tot tipus i que la quantitat de paquets disponibles en el repositori de Debian és major que el nombre de col·laboradors amb autorització per afegir paquets al repositori. En conseqüència, la col·laboració en el manteniment de paquets que ja estan en el repositori es valora molt positivament (i és més fàcil trobar un patrocinador) per la resta de desenvolupadors [7]. Per col·laborar en el manteniment de paquets ja disponibles en el repositori tens les següents opcions:

Si pots adoptar un paquet, descarrega el codi original (pots fer servir apt-get source nom_del_paquet) i examina-les amb atenció. Aquest document no explica amb detall el procés d'adopció de paquets. No hauria de ser difícil saber com funciona el paquet: el treball inicial de construcció ja està fet. Tot i així, molta de la informació d'aquest document et serà d'utilitat.

Si el paquet és nou i decideixes que t'agradaria posar-lo a disposició dels usuaris de Debian, has de seguir els passos indicats a continuació:

  • Aprèn el funcionament del programa i fes-ho servir una temporada (per comprovar la seva utilitat).

  • Comprova que no hi ha cap altra persona treballant en el paquet consultant la llista de paquets en els què s'està treballant. Si ningú hi treballa, envia un informe d'error de tipus «ITP» («Intent To Package») al wnpp meta-paquet fent servir el programa de comunicació d'errors reportbug (accessible en el menú d'eines del sistema). En cas contrari, pots contactar amb les persones que hi treballen: és possible que puguis col·laborar. També pots intentar trobar un altra programa interessant en el qual no hi treballi cap persona.

  • Cal que el programa tengui una llicència:

    • Per a paquets de la secció main cal que el programa s'ajusti a les Directrius de Debian per al programari (DFSG) lliure (consulta DFSG) i no ha de precisar la instal·lació de cap altre paquet que no pertanyi a la secció main en la compilació o execució com requereix la directiva de Debian («Debian Policy»).

    • Per a paquets de la secció contrib, la llicència cal que compleixi tots els requisits de la DFSG però pot precisar la instal·lació d'altres paquets que no siguin de la secció main en la compilació o execució.

    • Per a paquets de la secció non-free, no és necessari que la llicència compleixi tots els requisits de la DFSG però cal que permeti la distribució del programa.

    • Si tens dubtes a l'hora d'assignar el paquet a una secció, envia un correu amb el text de la llicència (en anglès) adreçat a debian-legal@lists.debian.org.

  • El programa no ha de ocasionar problemes de seguretat i/o manteniment en el sistema Debian..

    • Cal que el programa estigui ben documentat, que el codi sigui llegible i clar.

    • Cal que contactis amb l'autor o autors del programa per comprovar que accepten la construcció del paquet. És important que els autors continuïn amb el manteniment del programa de manera que puguis fer consultes sobre problemes específics del programa. No comencis a empaquetar un programa que no sigui mantingut pels autors.

    • El programa no s'ha d'executar com a «setuid root»: cal que no sigui «setuid» ni «setgid».

    • Cal que el programa no sigui un dimoni, o que s'instal·li en els directoris */sbin o obrir un port com a usuari administrador.

Aquesta llista t'ajudarà a començar amb garanties, i et salvaguardarà d'usuaris enfurismats si fas alguna cosa malament amb algun dimoni «setuid»...Quan tenguis més experiència en empaquetar, podràs fer aquest tipus de paquets.

Com a nou desenvolupador, s'aconsella l'adquisició d'experiència amb la construcció de paquets senzills i no s'aconsella la construcció de paquets complicats.

  • Paquets simples

    • un únic paquet binari, arquitectura = totes (col·lecció de dades com per exemple gràfics de fons de pantalla)

    • un únic paquet binari, arquitectura = totes (executables escrits en un llenguatge interpretat com per exemple POSIX)

  • Paquets de complexitat intermèdia

    • un únic paquet binari, arquitectura = totes (executables binaris ELF escrits en un llenguatge compilat com és ara C i C++)

    • paquet múltiple binari, arquitectura = qualsevol i totes (paquets amb executables binaris ELF i documentació)

    • el format de l'arxiu font no és ni tar.gz ni tar.bz2

    • paquets amb parts de les fonts que no es poden distribuir.

  • Paquets molt complexes

    • paquets amb mòduls d'intèrprets fets servir per altres paquets

    • paquets de biblioteques genèriques ELF que fan servir altres paquets

    • paquets amb múltiples binaris incloent paquets de biblioteques ELF

    • paquets de fonts amb fonts originals diverses

    • paquets amb mòduls del nucli

    • paquets amb pegats del nucli.

    • qualsevol paquet amb guions del desenvolupador no trivials

Construir paquets molt complexes no és molt difícil, però requereix tenir més coneixements. Hauràs de buscar una orientació específica per a cada funció complexa. Per exemple, alguns llenguatges tenen els seus propis documents de normes:

Hi ha un altre dit en llatí: fabricando fit faber (la pràctica fa la perfecció). És molt recomanable practicar i experimentar cada una de les etapes de construcció dels paquets Debian amb un paquet simple mentre es llegeix el tutorial. Un paquet «tarball» trivial hello-sh-1.0.tar.gz generat amb el següent exemple és un bon punt de partida [8].

$ mkdir -p hello-sh/hello-sh-1.0; cd hello-sh/hello-sh-1.0
$ cat > hello <<EOF
#!/bin/sh
# (C) 2011 Foo Bar, GPL2+
echo "Hello!"
EOF
$ chmod 755 hello
$ cd ..
$ tar -cvzf hello-sh-1.0.tar.gz hello-sh-1.0

La primera passa és trobar i descarregar el codi font original del programa. Les fonts dels programes lliures de GNU/Linux és habitual que es distribueixin en fitxers amb format tar+gzip amb extensió .tar.gz o amb format tar+bzip2 amb extensió .tar.bz2, i generalment tenen un directori amb el nom programa-versió amb tots els fitxers del codi font.

Si la darrera versió del codi font és a un sistema VCS tipus Git, «Subversion» o a un repositori CVS, pots descarregar-ho executant git clone, cvs co o svn co i, a continuació ho comprimeixes en un arxiu amb format tar+gzip executant l'opció --exclude-vcs.

Si el programa està disponible en una altre format (pot ésser un arxiu acabat en .Z o .zip[9]), ho descomprimeixes amb l'eina adequada i el tornes a empaquetar adequadament.

Si algun dels continguts del codi font del teu programa no compleix les directrius DFSG, has de descomprimir-ho per eliminar-los hi tornar a comprimir-los afegint dfsg a la cadena de la versió del codi original.

Com exemple, faré servir el programa gentoo, un gestor de fitxers de X11 fet amb GTK+ [10].

Fes un nou directori al teu directori d'usuari amb el nom debian o deb o el que trobis més adequat (p.e. ~/gentoo/ és molt adequat). Copia en aquest nou directori el fitxer del codi font i extreu el seu contingut executant tar xzf gentoo-0.9.12.tar.gz. Comprova que no hi ha hagut errors, fins i tot els més irrellevants, degut a què és possible que hi hagi errors en desempaquetar-ho en sistemes d'altres persones que no ignorin aquestes errades. En el terminal hauràs fet el següent:

$ mkdir ~/gentoo ; cd ~/gentoo
$ wget http://www.example.org/gentoo-0.9.12.tar.gz
$ tar xvzf gentoo-0.9.12.tar.gz
$ ls -F
gentoo-0.9.12/
gentoo-0.9.12.tar.gz

Ara tens un nou directori amb el nom gentoo-0.9.12. Accedeix en aquest directori i llegeix atentament la documentació del programa, normalment en fitxers amb el nom README*, INSTALL*, *.lsm o *.html. Hi haurà instruccions per a la compilació i instal·lació del programa (probablement la instal·lació es farà a /usr/local/bin, però veurem a Secció 3.3, «La instal lació dels arxius al seu destí» que no és la destinació correcta).

Per començar la construcció del paquet, cal fer-ho amb el directori del codi font «net», o simplement només amb els fitxers de l'arxiu comprimit del codi font.

Alguns programes tenen un arxiu Makefile i és possible compilar-los simplement executant make [11]. Molts d'ells permeten executar make check, per fer comprovacions. La instal·lació en el directori de destí es fa executant make install.

Una vegada s'ha compilat el programa, prova'l i comprova que tot funciona correctament i que no es genera cap errada en el sistema en l'execució i/o instal·lació.

L'execució de l'ordre make clean (o make distclean) eliminarà del directori els fitxers generats per a la compilació i que són innecessaris. Habitualment, serà possible des-instal·lar el programa amb l'ordre make uninstall.

La majoria de programes lliures estan escrits en llenguatge C i C++. Molts fan servir les «Autotools» i «CMake» per compilar en diferents arquitectures. Aquestes eines generen un arxiu Makefile i d'altres fitxers necessaris per a la compilació. Així, molts programes es compilen i instal·len amb l'execució de make; make install.

Les Autotools són el sistema de compilació GNU que comprèn Autoconf, Automake (si l'entrada no existeix a la Viquipèdia, s'ha posat l'enllaç a la versió en castellà), Libtool i gettext. Confirmaràs que el programa fa servir les «autoools» per la presència dels arxius configure.ac, Makefile.am, i Makefile.in [12].

La primera etapa en l'ús de les «Autotools» és l'execució de l'ordre (per l'autor del codi font) autoreconf -i -f amb la qual es generen, fent servir el fitxers font (a l'esquerra del diagrama) els fitxers (a la dreta del diagrama) que després farà servir l'ordre «configure».

configure.ac-----+-> autoreconf -+-> configure
Makefile.am -----+        |      +-> Makefile.in
src/Makefile.am -+        |      +-> src/Makefile.in
                          |      +-> config.h.in
                      automake
                      aclocal
                      aclocal.m4
                      autoheader

Per a l'edició dels fitxers configure.ac i Makefile.am cal conèixer el funcionament de autoconf i automake. Consulta info autoconf i info automake (executant les ordres en el terminal).

La segona etapa del pla de treball amb «Autotools» és l'obtenció de les fonts i l'execució de ./configure && make en el directori del codi font per compilar el programa generant el fitxer binari.

Makefile.in -----+                +-> Makefile -----+-> make -> binary
src/Makefile.in -+-> ./configure -+-> src/Makefile -+
config.h.in -----+                +-> config.h -----+
                 |
  config.status -+
  config.guess --+

Pots fer canvis en el fitxer Makefile com és el directori d'instal·lació predeterminat fent servir les opcions ./configure --prefix=/usr.

Tot i què no és necessari, l'actualització del fitxer configure i dels altres fitxers amb l'ordre autoreconf -i -f és la forma més adient per comprovar la compatibilitat del codi font [13].

CMake (en el moment de fer aquesta traducció, aquesta entrada no existeix a la Viquipèdia en català) és un sistema de compilació alternatiu. Els programes que fan servir aquest sistema de compilació tenen un arxiu CMakeLists.txt en el codi font.

Si el codi font te el nom gentoo-0.9.12.tar.gz, pots fer servir gentoo com a nom del paquet (de les fonts) i 0.9.12 com a codi de la versió del codi font. Aquestes denominacions es fan servir a l'arxiu debian/changelog que es descriu més endavant a Secció 4.3, «El fitxer changelog

Encara que aquest enfocament simple funciona la majoria de les vegades, pot ésser necessari ajustar el nom del paquet i versió del codi font canviant el nom de l'arxiu amb el codi font segons les Normes Debian i les convencions vigents.

Cal triar el nom del paquet de manera que tengui només lletres minúscules (a-z), dígits (0-9), els símbols de suma (+) i guió (-) i punts (.). Al menys ha de tenir 2 caràcters de longitud, començar amb un caràcter alfanumèric i no coincidir amb algun dels paquets ja existents. És una bona pràctica mantenir la longitud del nom per davall dels 30 caràcters [14].

Si l'autor original fa servir termes genèrics com prova de nom, és convenient canviar el nom de forma que identifiqui el seu contingut i evitar «embrutar» l'espai de noms [15].

Has de triar la versió del codi font de manera que tengui només caràcters alfanumèrics (0-9 A-Z a-z), el signe més (+), titllis (~) i punts (.). Cal que comenci per un dígit (0-9) [16]. És una bona pràctica mantenir la seva longitud per davall dels 8 caràcters sempre que sigui possible [17].

Si l'autor original no fa servir el format més habitual per la versió (com és ara 2.30.32) sinó que utilitza algun tipus de data com 09Oct23, una cadena aleatòria o un valor «hash» VCS, assegura't que ho elimines de la versió del codi font. Aquesta informació s'ha de registrar a l'arxiu debian/changelog. Si t'has d'inventar una cadena de versió, fes servir el format AAAAMMDD com per exemple 20110429 per a la versió del codi font. Així es garanteix que l'ordre dpkg interpreti correctament les versions posteriors com a actualitzacions. Si cal garantir una transició fluida al format de la versió més habitual, com 0.1 en el futur, fes servir el format 0~AAMMDD format com 0~110429 per a la versió principal.

El codi de versió [18] serà comparat per dpkg(1) de la següent manera.

$ dpkg --compare-versions versió_1 op versió_2

La norma de comparació de versions es pot resumir com:

  • Les cadenes es comparen des del cap fins la cua.

  • Les lletres són anteriors als dígits.

  • Els nombres es comparen com enters.

  • Les lletres es comparen per l'ordre del seu codi ASCII.

  • Hi ha normes especials per al punt (.), signe més (+) i ~ com es mostra a continuació:

    0.0 < 0.5 < 0.10 < 0.99 < 1 < 1.0~rc1 < 1.0 < 1.0+b1 < 1.0+nmu1 < 1.1 < 2.0

Un cas complicat es produeix quan s'allibera una versió del codi font gentoo-0.9.12-ReleaseCandidate-99.tar.gz com a versió prèvia de gentoo-0.9.12.tar.gz. Cal assegurar que l'actualització funcionarà correctament canviant el nom de codi font per gentoo-0.9.12~rc99.tar.gz.

Comença per configurar les variables d'entorn del shell Bash $DEBEMAIL i $DEBFULLNAME que faran servir les eines de manteniment de Debian per tal d'obtenir el teu nom i adreça electrònica com s'indica a continuació[19].

$ cat >>~/.bashrc <<EOF
DEBEMAIL="your.email.address@example.org"
DEBFULLNAME="Firstname Lastname"
export DEBEMAIL DEBFULLNAME
EOF
$ . ~/.bashrc

Els paquets normals Debian són paquets de Debian no nadius construïts a partir dels programes originals. Si vols construir un paquet no nadiu Debian del codi font gentoo-0.9.12.tar.gz, pots construir el paquet no nadiu inicial Debian fent servir l'ordre dh_make de la següent manera.

$ cd ~/gentoo
$ wget http://example.org/gentoo-0.9.12.tar.gz
$ tar -xvzf gentoo-0.9.12.tar.gz
$ cd gentoo-0.9.12
$ dh_make -f ../gentoo-0.9.12.tar.gz

Caldrà canviar el nom del fitxer amb el codi font [20]. Consulta dh_make(8) per a una descripció més detallada.

En haver executat l'ordre, caldrà respondre a algunes preguntes sobre el paquet. «Gentoo» és un paquet binari simple (només crea un arxiu binari) i, per tant, només un arxiu .deb. Per això, seleccionaràs la primera opció amb la tecla s. Comprova la informació que surt en pantalla i confirma polsant la tecla ENTER [21].

Desprès d'executar l'ordre dh_make, es fa una còpia del fitxer amb el codi original amb el nom gentoo_0.9.12.orig.tar.gz en el directori arrel per facilitar la construcció del paquet de fonts no nadiu de Debian amb el fitxer debian.tar.gz.

$ cd ~/gentoo ; ls -F
gentoo-0.9.12/
gentoo-0.9.12.tar.gz
gentoo_0.9.12.orig.tar.gz

Posa atenció en els dos canvis en el nom del fitxer gentoo_0.9.12.orig.tar.gz:

  • El nom del paquet i de la versió estan separats per «_».

  • S'ha afegit .orig abans de l'extensió .tar.gz.

Fitxa't que hi ha nous fitxers (de plantilla) en el directori debian dels quals es parlarà en Capítol 4, Fitxers necessaris en el directori debian. i Capítol 5, Altres fitxers del directori debian.. El procés d'empaquetament no està totalment automatitzat. La modificació dels fitxers Debian s'explicarà a Capítol 3, Modificar les fonts originals.. A continuació es compilarà el paquet Debian en l'apartat Capítol 6, Construir el paquet., la revisió del resultat a l'apartat Capítol 7, Com comprovar el teu paquet per trobar errors. i la transferència del paquet al repositori a Capítol 9, Enviar el paquet.. S'explicarà cada etapa a continuació.

Si casualment elimines algun dels fitxers de plantilles del directori «debian», pots tornar a generar-los executant dh_make amb l'opció --addmissing des del directori de les fonts.

L'actualització d'un paquet ja construït és un procés més complex: es probable que s'hagi construït amb procediments distints als que es fan servir actualment. Es millor treballar amb paquets actualitzats per aprendre els procediments bàsics de la construcció de paquets. Per empaquetar una revisió o una nova versió del teu paquet en el futur, faràs servir un procediment distint. Tot això s'explicarà a la secció Capítol 8, Actualitzar el paquet..

Observa que l'arxiu font pot ésser que no tengui cap sistema de construcció dels discutits a Secció 2.4, «Sistemes de compilació simples» i a Secció 2.5, «Sistemes de compilació populars». Podria ser simplement una col·llecció de dades gràfiques. La instal lació dels arxius es pot fer utilitzant només els arxius de configuració del sistema debhelper com ara debian/install (consulta Secció 5.11, «Fitxer install).



[4] Per a paquets no nadius Debian construïts amb l'antic format 1.0, es fa servir nom_del_paquet_versió-revisió.diff.gz

[5] Consulta 5.6.1 "Source", 5.6.7 "Package", i 5.6.12 "Version". El codi de l'arquitectura del paquet segueix el Debian Policy Manual, 5.6.8 "Architecture" i s'assigna automàticament en el procés de construcció del paquet.

[7] Tot i així, hi ha nous programes que són d'interès per a Debian.

[8] No et preocupis per l'arxiu Makefile perdut. Pots instal·lar l'ordre hello fent servir l'ordre debhelper com s'ha explicat a Secció 5.11, «Fitxer install o modificant les fonts originals afegint un nou Makefile amb l'objectiu install com a Capítol 3, Modificar les fonts originals..

[9] Pots identificar el format de l'arxius fent servir l'ordre file.

[10] Aquest programa ja està empaquetat. La versió actual fa servir «Autotools» en la seva construcció i ha canviat molt respecte a la versió 0.9.12 feta servir en els exemples.

[11] Molts programes moderns vénen amb un guió configure que genera l'arxiu Makefile personalitzat pel sistema en què s'executa.

[12] «Autotools» és extens per explicar-ho en aquest petit tutorial. En aquesta secció només s'expliquen aspectes clau i algunes referències. Assegura't que llegeixes el Autotools Tutorial i /usr/share/doc/autotools-dev/README.Debian.gz i si has de fer servir «Autotools».

[13] Pots automatitzar el procés utilitzant dh-autoreconf. Consulta Secció 4.4.3, «Personalització del fitxer rules.

[14] La longitud predeterminada pel nom del paquet de l'ordre aptitude és 30. Per a més del 90% dels paquets, el nom del paquet té menys de 24 caràcters.

[15] Si segueixes les Debian Developer's Reference 5.1. "New packages", el procés d'ITP resoldrà aquest tipus de qüestions.

[16] Aquesta norma més estricta hauria d'ajudar a evitar noms d'arxius confusos.

[17] La longitud predeterminada pel codi de versió de l'ordre aptitude és 10. El codi de revisió Debian precedit per un guió en consumeix 2. Per a més del 80% dels paquets, la versió del codi font té una longitud inferior a 8 caràcters i el codi de la revisió Debian menys de 2. Per a més del 90% dels paquets, la versió del codi font té menys de 10 caràcters i la revisió Debian menys de 3.

[18] Les cadenes de versió poden ésser la versió del codi font (versió), la revisió Debian (revisió), o versió (versió-revisió). Consulta Secció 8.1, «Nova revisió Debian del paquet.» per saber com cal incrementar la revisió Debian.

[19] El text mostrat a continuació dona per suposat que fas servir «Bash» com a intèrpret d'ordres. Si fas sevir altres intèrprets, com és ara «Z shell», hauràs de fer servir els seus arxius de configuració en lloc de ~/.bashrc.

[20] Si el fitxer amb el codi font ja té un directori debian amb fitxers, executa l'ordre dh_make amb l'opció --addmissing. El nou format de paquet 3.0 (quilt) és molt robust i treballarà bé amb aquests paquets. Així s'actualitzarà el contingut dels fitxers de l'autor original per al teu paquet Debian.

[21] Les opcions sobre el tipus de paquet són les següents: s per a un binari, i per a un paquet independent de l'arquitectura (paquet de codi font o de documentació), m per a paquets amb més d'un arxiu binari, l per a biblioteques, k per a un mòdul del nucli («kernel»), n per a un pegat del nucli i b per a paquets cdbs. Aquest document es centra amb l'ús del paquet debhelper i l'ordre dh per a la construcció de paquets amb un binari i tracta només parcialment el seu ús en la construcció de paquets independents de l'arquitectura i amb més d'un arxiu binari. El paquet cdbs proporciona guions alternatius a l'ordre dh i no s'explica en aquest document.