Translation(s): English - Español - Italiano - Català



Introducció a l'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:

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 "fitxer d'arxiu 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 (paquet tar és argot informàtic). El paquet tar es d'on es crea el paquet Debian. Quan es disposa d'un paquet tar d'upstream, el següent pas és crear el paquet Debian de codi font, des del quual es pot construir el paquet Debian binari, que és el que s'acaba instal·lant.

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

  1. El paquet tar d'upstream, reanomenat per 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: seria més simple tenir-ho tot en un únic fitxer. Però mantenint el paquet tar d'upstream separat de qualsevol canvi específic de Debian s'aconsegueix un gran estalvi d'espai en disc i d'ample de banda. També permet veure més fàcilment quins canvis s'han hagut de realitzar per a Debian.

Els passos del procés d'empaquetatge

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

  1. reanomenar el paquet tar d'upstream per tal de 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: reanomenar el paquet tar

Les eines d'empaquetat de Debian assumeixen que el paquet tar d'upstream té un nom molt 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 de posar en minúscules, i pot contenir lletres, dígits, i guions. D'altres caràcters també estan permesos.

Si el desenvolupador d'upstream fa servir un nom que sembla un bon nom per a un paquet Debian de codi font, hauries de fer-lo servir. Si no és així, canvia el nom del paquet d'upstream el mínim possible perquè coincideixi amb els criteris de Debian. En aquest cas, el nom del paquet d'upstream és correcte, "hithere", per tant no ens hem de preocupar.

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 que tingui per nom el nom del paquet de codi font i la versió d'upstream, i un guió enmig.

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 es 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 del codi font.

# 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 allò que s'ha canviat al codi font d'upstream, però pot ser útil per als usuaris per tal de conèixer aquests canvis. Com que estem fent la primera versió, no hi ha cap històric. Tot i això, hem de fer una entrada a l'històric, perquè les eines d'empaquetament llegeixen certa informació de l'històric de canvis. El més important és que 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 alguns camps obligatoris, però de moment no s'expliquen. Al fitxer debian/control, hi ha dos paràgrafs.

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

"Source:"
camp que indica el nom del paquet de codi font.
"Maintainer:"
camp 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 poder construir el paquet. Poden o no ser necessaris per a l'ús del paquet.

El segon paràgraf descriu el paquet binari construït des del codi font. De fet, poden haver varis paquets binaris construïts des del mateix codi font.

"Package:"
és el nom del paquet binari. El nom pot ser diferent al 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 d'arquitectures en total , així que el suport per a arquitectures es crucial. El camp "Architecture:" pot contenir noms d'arquitectures particulars, però sol contenir un dels dos valors especials següents:
"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, de manera que no fa suposicions respecte 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 aquest camp s'indiquen els paquets que han d'estar instal·lats per tal que el programa del paquet binari pugui funcionar. Llistar aquestes dependències manualment és tediós i propens a error. Per fer aquesta tasca, és necessari posar el valor "màgic" ${shlibs:Depends}. Les altres coses "màgiques" són per a debhelper. Com el valor "màgic" {misc:Depends}. El valor shlibs és per a les dependències de llibreries compartides, el valor misc és per a d'altres coses que fa debhelper. Per a altres dependències, és necessari que ho afegeixis manualment a Depends o a Build-Depends. Les parts ${...} màgiques només funcionen a Depends.

"Description:"
és la descripció del paquet. Està pensada per ser útil als usuaris.

debian/copyright

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

Per a Debian, aquest fitxer és usat per seguir la informació legal relacionada amb el copyright d'aquest paquet. Però no és important des del punt de vista tècnic. Per ara, concretarem 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 tot i que és el mateix número que la versió d'upstream, això només és una coincidència.

Passos 4 i 5: construir el paquet

Ara es pot construir el paquet. L'ordre per fer-ho és:

debuild -us -uc

Hi ha vàries ordres que podem usar per fer això, però aquesta és la que farem servir. En 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 instal·lar el programa compilat en una ubicació incorrecta.

Hi ha unes quantes coses que estan passant: la primera es deu a 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 algun lloc dins del subdirectori debian/.

Creem un subconjunt 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 s'ha d'instal·lar directament a usr.

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

La manera correcta d'arreglar això es canviar el fitxer debian/rules de manera que indiqui a 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

De nou, estem fent una mica de màgia. Per entendre això és necessari entendre com funcionen els Makefiles, i com s'executen les diferents etapes de debhelper.

Per ara, es pot resumir 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 substituir aquesta etapa, ho fem amb una regla al fitxer debian/rules anomenada override_dh_auto_install.

L'última línia del fitxer debian/rules fa ús de la tecnologia dels 1970s per invocar el Makefile d'upstream des del fitxer debian/rules amb els arguments correctes.

Intentem construir el paquet un altre vegada. Segueix fallant!

Aquest cop, aquesta és l'ordre que falla:

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

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

La manera ideal seria que el Makefile d'upstream creï el directori, però en aquest cas al desenvolupador d'upstream li va fer mandra fer-ho.

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

S'ha de crear un fitxer anomenat debian/hithere.dirs, que contingui:

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 ha alguns petits problemes.

L'ordre debuild executa l'eina lintian, que comprova alguns errors comuns en construir el paquet. Ens reporta alguns errors per a aquest 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 cap d'ells hagi de donar problemes per tal de provar el paquet. Així que de moment, ignorem aquests errors.

Mirem en el directori pare per 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 aquesta ordre en un ordinador que no t'importi 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 l'ordre.

# hithere

Funciona! Però no és perfecte. Recordem que l'ordre lintian detectava alguns errors, el fitxer debian/copyright està buit, etc.

Tenim un paquet que funciona, però 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 tal que el teu paquet sigui fàcil d'instal·lar. La millor eina que conec per fer això és reprepro.

Per provar més el teu paquet, pots mirar l'eina anomenada piuparts. (Originalment, la vaig escriure jo, per tant és perfecta i mai té cap error. er...)

I, finalment, si vols començar a fer canvis al codi font d'upstream, hauràs d'aprendre l'eina quilt.

Altres coses que potser voldràs 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 crec que Debian no suporta paquets de vàries arquitecutres, però parlarem dels paquets"Architecture: all" més tard.

PREGUNTA: Si us plau, aclareix què s'ha de fer amb els paquets que ja estan en forma binària, 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; tot i que mai ho he hagut de fer.

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

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

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

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

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

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 ha dit que el fitxer compat ha de tenir el número màgic 7, s'ha d'assumir que això significa que ha de ser un únic número produit per l'execució de l'ordre 'echo 7 >debian/compat'?

RESPOSTA: Sí, un únic caràcter 7 és suficient per al fitxer debian/compat

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

RESPOSTA: Crec que et refereixes o als paquets natius (en els quals el número de versió serà 1.0, i no 1.0-1); o al format dels paquets penjats per un no mantenidor, en aquest cas necessitaria una explicació massa detallada per a aquesta sessió, per tal de cobrir 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 desempaquetar un paquet de codi font de Debian després 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 compilació creuada, i no crec que hi hagi una manera fàcil per a fer-ho. Hi han eines per fer-ho, però no estic familiaritzat amb elles.

PREGUNTA: Quina és la diferencia entre Depends i Build-Depends, en quin cas haig de fer servir només Depends en comptes de Build-Depends?

RESPOSTA: Les dependències de Build-Depends només són necessàries durant el procés de construcció del paquet, mentre s'està compilant i quan el conjunt de tests s'està executant. Les dependències de Depends només són necessàries quan el paquet s'està fent servir, després de ser instal·lat. En alguns casos hi ha dependències que són de construcció i d'execució alhora, en aquests casos, has de posar-les a Build-Depends i a Depends.

Per exemple, si un paquet conté un script PHP, però que no s'executa quan s'està construint el paquet, PHP anirà a Depends i no a Build-Depends.

Però, si l'script PHP només executa una prova i no s'inclou en el paquet binari, PHP estarà a Build-Depends i no a Depends.

PREGUNTA: Poden haver dependències a Build-Depends que no tinguin dependències corresponents a Depends? Estic pensant en llibreries enllaçades de forma estàtica.

RESPOSTA: Les dependències de Depends i de Build-Depends estan molt separades i això és correcte (des del punt de vista de l'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 un NMU, has d'escriure el teu nom al camp Uploader, al camp Mantainer o a cap camp?

RESPOSTA: (per dapal) A cap, però a la primera línia del fitxer changelog ha de posar "Non-mantainer upload"

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

RESPOSTA: Sí, és correcte, no hi ha per què preocupar-se.

PREGUNTA: Hi ha un altre paquet per al paquet de codi font o és 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'"Architecure" tindran efecte sobre el paquet de codi font (en el procés de construcció) o sobre el paquet binari (a la instal·lació i execució).

RESPOSTA: El camp "Architecture" indica a qualsevol persona que vulgui construir el paquet si es pot fer en una arquitectura de processador concreta, si el paquet és 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 .. alguna altra ordre semblant?

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

PREGUNTA: L'heurística es bona, però què passa si es necessita passar --alguna-cosa-especial a l'script configure o arguments a cmake, l'heurística suporta els paquets font que necessiten executar l'eina ./waf o altres eines per construir-lo?

RESPOSTA: La resposta de dapal es correcta: <dapal> lilith: fent servir dh7, si necessites passar alguna cosa a ./configure, només has de escriure alguna cosa semblant a: override_dh_auto_configure <TAB>dh_auto_configure -- --els-teus-paràmetres dh té un excelent mecanisme d'extensions/substitucions que et permet substituir certes parts, es molt fàcil de fer servir, un cop t'has llegit la documentació.

PREGUNTA: On es pot trobar la documentació per a substituir coses de debhelper7?

RESPOSTA: dh executa una seqüencia específica d'ordres per tal de construir un paquet; cada ordre s'anomena dh_alguna_cosa, i cada ordre pot ser substituïda afegint una entrada al fitxer debian/rules de nom override_dh_alguna_cosa.

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

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

RESPOSTA: Jo sempre executo les ordres d'empaquetament dins del directori hithere-1.0, i en general tinc un directori per sobre anomenat hithere però que realment no és necessari, és per 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: Ah, no sé quina és la millor manera de fer-ho, però bàsicament: descomprimir el codi font d'upstream a un nou directori, copiar el directori debian/* des del paquet vell, actualitzar el fitxer debian/changelog ("dch -v 1.2.3-4") i intentar construir-lo, arreglant qualsevol cosa que s'espatlli. Aquest no és de fet un bon procés, però per això hauràs d'aprendre quilt, i possiblement com usar un gestor de versions amb els paquets Debian, i això es un tema massa extens 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 tal que compleixin les necessitats d'algunes persones. Per fer 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? Podria ser una paquet així un paquet oficial?

RESPOSTA: El millor conjunt de normes que indiquen què pot fer o què ha de 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 fer-ho.

Consulteu també