Sumari
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.
Obtindre una còpia del codi font del programa, normalment en un arxiu comprimit en format «tar».
nom_del_paquet
-versió
.tar.gz
Afegir les modificacions específiques de la construcció del paquet Debian a
les fonts del programa en el directori debian
, i
generar un paquet font no nadiu (o sigui, el conjunt d'arxius d'entrada que
es fan servir en la compilació del paquet Debian).
nom_del_paquet
_versió
.orig.tar.gz
nom_del_paquet
_versió
-revisió
.debian.tar.gz
[4]nom_del_paquet
_versió
-revisió
.dsc
Construir paquets binaris Debian, habitualment paquets ordinaris per a la
instal·lació en format .deb
(o en format
.udeb
, fet servir per l'instal·lador de Debian) a partir
del paquet font Debian.
nom_del_paquet
_versió
-revisió
_arquitectura
.deb
Observa que el caràcter que separa
i
nom_del_paquet
s'ha canviat de
versió
-
(guió) a l'arxiu comprimit original a
_
(guió baix) en el nom del paquet Debian.
En els noms del arxius anteriors, cal substituir
pel nom del paquet,
nom_del_paquet
pel codi de versió del codi font,
versió
pel codi de la
revisió Debian i
revisió
per l'arquitectura del paquet com es defineix en el
Manual de Normes de Debian [5].
arquitectura
Si en canvi, estàs treballant amb un paquet específic de Debian sense autor original, el flux de treball típic de la construcció de paquets de Debian és més senzill.
Genera un paquet nadiu de fonts Debian en el format 3.0
(native)
fent servir un únic arxiu comprimit en format «tar»
afegint tots els arxius.
nom_del_paquet
_versió
.tar.gz
nom_del_paquet
_versió
.dsc
Construcció de paquets binaris Debian des de paquets de fonts Debian nadius.
nom_del_paquet
_versió
_arquitectura
.deb
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:
l'ordre aptitude.
la pàgina web paquets Debian.
pàgina web Debian Package Tracking System (Sistema de seguiment de paquets de Debian)
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:
Fer-te càrrec de paquets orfes d'ús freqüent
unir-te als equips de desenvolupadors.
Selecciona errors dels paquets més populars.
Selecciona paquets QA o NMU.
Si pots adoptar un paquet, descarrega el codi original (pots fer servir
apt-get source
)
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.
nom_del_paquet
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
amb tots els fitxers del codi font.
programa
-versió
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 -> binari
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-versionsversió_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(1) 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
[21].
ENTER
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 8, 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 9, 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
.”).
Si el paquet conté arxius de fonts que només es distribueixen per a Debian,
possiblement només per a ús local, és més simple construir un paquet nadiu
Debian. Si tens els arxius de fonts a
~/el_meu_paquet-1.0
, pots generar el paquet nadiu
inicial Debian executant l'ordre dh_make de la següent
manera.
$ cd ~/el_meu_paquet-1.0 $ dh_make --native
Llavors el directori debian
i el seu contingut es
genera igual que a Secció 2.8, “Paquet Debian no nadiu inicial.”. No es genera un
arxiu «tarball» degut a que es tracta d'un arxiu nadiu Debian. Però aquesta
és l'única diferència. La resta de les etapes de construcció del paquet són
pràcticament iguals.
[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 Manual de Normes Debian: 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 file:///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 (
),
la revisió Debian
(versió
), o versió
(revisió
).
Consulta Secció 9.1, “Nova revisió Debian del paquet.” per saber com cal incrementar la
revisió Debian.
versió
-revisió
[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.