Differences between revisions 3 and 4
Revision 3 as of 2011-01-07 18:20:01
Size: 27502
Editor: ?DavidPinilla
Comment:
Revision 4 as of 2011-01-07 19:22:13
Size: 27899
Editor: ?DavidPinilla
Comment:
Deletions are marked like this. Additions are marked like this.
Line 37: Line 37:
Els tres conceptes centrals són el "el paquet tarball 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 upstream alliberarà una versió del seu programari, i el resultat d'aquest alliberament serà el "el arxivador del codi font upstream " o '''paquet tarball'''.

Un paquet tarball es un fitxer amb extensió ''.tar.gz'' o ''.tgz'' que crea el desenvolupador upstream (''el paquet tarball'' es argot informàtic).
El paquet tarball es d'on es crea el paquet Debian.
Quan es disposa de un paquet tarball d'upstream, el següent pas és crea el paquet Debian de codi font, des del que es pot construir el paquet Debian binari, que es el que s'instal·la.
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 upstream alliberarà una versió del seu programari, i el resultat d'aquest alliberament serà el "el arxivador del codi font upstream " o '''paquet tar'''.

Un paquet tar es un fitxer amb extensió ''.tar.gz'' o ''.tgz'' que crea el desenvolupador 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 crea el paquet Debian de codi font, des del que es pot construir el paquet Debian binari, que es el que s'instal·la.
Line 45: Line 45:
 1. El paquet tarball d'upstream, renombrat per a seguir un patró sistemàtic.  1. El paquet tar d'upstream, renombrat per a seguir un patró sistemàtic.
Line 50: Line 50:
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 fitxer tarball d'upstream separat de qualsevol canvi especific de Debian s'aconsegueix un gran estalvi d'espai en disc i d'ample de banda. 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.
Line 57: Line 57:
 1. renombrar el paquet tarball d'upstream per a seguir un patró específic
 2. descomprimir el paquet tarball d'upstream
 1. renombrar el paquet tar d'upstream per a seguir un patró específic
 2. descomprimir el paquet tar d'upstream
Line 64: Line 64:
Per a aquest tutorial Lars va fer servir [[http://code.liw.fi/hithere/hithere-1.0.tar.gz|aquest paquet tarball]].

=== Pas 1: renombrar el nom del paquet tarball ===

Les eines d'empaquetat de Deb
ian assumeixen que el paquet tarball d'upstream té un nom específic.
Per a aquest tutorial Lars va fer servir [[http://code.liw.fi/hithere/hithere-1.0.tar.gz|aquest paquet tar]].

=== Pas 1: renombrar el nom del paquet tar ===

Les eines d'empaquetat de De
bian assumeixen que el paquet tar d'upstream té un nom específic.
Line 73: Line 73:
If the upstream developer uses a name that looks like a good Debian source package name, then you should use that.
Otherwise, change the upstream name as little as possible to make it fit for Debian.
In this case, upstream has wisely picked a suitable name, "hithere", so there's no need to worry about it.

We should end up with a file called '''hithere_1.0.orig.tar.gz'''.

Note that there is an underscore, not a dash, in the name.
This is important, because the packaging tools are picky.
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 coincideix 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.
Line 84: Line 84:
=== Step 2: unpack the tarball ===


We should have a directory called "hithere-1.0".
In general, the sources should go into a directory named after the source package name and upstream version, with a hyphen (not underscore) in between.

This is again because the packaging tools are picky.

In this case, upstream has again been wise and made the tarball pack into the right subdirectory.
=== 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.
Line 96: Line 96:
=== Step 3: add Debian packaging files ===

All of these files go into the ''debian/'' subdirectory inside the source tree.
=== Step 3: afegir els fitxers del paquet Debian ===

Tots aquests fitxers han d'anar dins del subdirectori ''debian/'' dins de l'arbre.
Line 105: Line 105:
There are a bunch of files we need to provide. Let's look at them in order. Hi ha una sèrie de fitxers que hem de proporcionar. Anem a veure'ls en ordre.
Line 109: Line 109:
First file is '''debian/changelog'''. This is the log of changes to the Debian package.

It does not need to list everything that has changed in upstream code, though it can be helpful to users to summarize those changes, too.
Since we are now making the first version, there is nothing to log.
However, we still need to make a changelog entry, because the packaging tools read certain information from the changelog.
Most importantly, they read the version of the package.

''debian/changelog'' has a very particular format. The easiest way to create it is to use the '''''dch''''' tool.
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ò tenim que fer una entrada a l'històric, perquè les eines de empaquetament llegeixen certa informació del històric de canvis.
El més importatn, llegeixen la versió del paquet.

El fitxer ''debian/changelog'' té un format molt particular. La forma més facil de crear-lo és fer servir l'eina '''''dch'''''.
Line 130: Line 130:
A couple of notes:

 * The '''''hithere''''' part MUST be the same as the source package name. '''''1.0-1''''' is the version. The '''''1.0''''' part is the upstream version. The '''''-1''''' part is the __Debian__ version: the first version of the Debian package of upstream version 1.0. If the Debian package has a bug, and it gets fixed, but the upstream version remains the same, then the next version of the package will be called 1.0-2. Then 1.0-3, and so on.

 * '''''UNRELEASED''''' is called the upload target. It tells the upload tool where the binary package should be uploaded. '''''UNRELEASED''''' means the package is not yet ready to be uploaded. It's a good idea to keep the '''''UNRELEASED''''' there so you don't upload by mistake.

 * Ignore '''''urgency=low''''' for now. Just keep it there.
Unes quantes notes:

 * La part '''''hithere''''' HA DE SER igual que el nom del paquet font.'''''1.0-1''''' és la versió. La part '''''1.0''''' és la versió d'upstream. La part '''''-1''''' és la versió de __Debian__: la primera versió del paquet Debian de la versió d'upstream 1.0. Si el paquet Debian conté un bug, i aquest és reparat, però la versió d'upstream és la mateixa, la propera versió del paquet serà la 1.0-2. La següent 1.0-3, i les següents seguint el patró.
 *'''''UNRELEASED''''' és el destí de pujada. Això indica a l'eina de pujada on s'ha de pujar el paquet binari. '''''UNRELEASED''''' significa que el paquet no està perparat per a ser pujat. Es una bona idea mantenir l'estat com a '''''UNRELEASED''''' , per així evitar pujar el paquet per equivocació.

 * Ignora la part '''''urgency=low''''' per ara. Deixa-ho així.
Line 138: Line 137:
 * The '''''(Closes: #XXXXXX)''''' bit is for closing bugs when the package is uploaded. This is the usual way in which bugs are closed in Debian: when the package that fixes the bug is uploaded, the bug tracker notices this and marks the bug as closed. We can just remove the '''''(Closes...)''''' bit. Or not. It doesn't matter right now.

 * The final line in the changelog tells who made this version of the package, and when. The dch tool tries to guess the name and e-mail address, but you can configure it with the right details. See the dch(1) manual page for details.
 * La part '''''(Closes: #XXXXXX)''''' es per a tancar els errors quan el paquet és pujat. Aquesta és la manera típica en la que els errors es tanquen a Debian: quan un paquet que arregla un problema és pujat, l'eina de seguiment d'errors ho detecta, i marca l'error com a tancat. Es pot eliminar '''''(Closes...)''''' . O no, en aquest cas, no importa.

 * L'ultima línia del fitxer changelog indica qui ha fet la aquesta versió del paquet, i quan. La utilitat dch intenta adivinar el nom i la direcció de correu, però es pot configurar amb les dades correctes. Consulta la pàgina del manual dch(1) per als detalls.
Line 146: Line 145:
This file should contain the number 7. This is a magic number. Do not put any other number in there.
'''debian/compat''' specifies the "compatibility level" for the debhelper tool. We don't need to go into what that means, right now.
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ò.
Line 152: Line 151:
The control file describes the source and binary package, and gives some information about them, such as their names, who the package maintainer is, and so on.
Below an example of what it might look like.
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 paquetwho the package maintainer is, i així successivament.
A continuació hi ha un exemple de com tindria que quedar el fitxer.
Line 171: Line 170:
There are several required fields, but you can just treat them as magic, for now.
So, in debian/control, there are two paragraphs.

The first one describes the '''source package''':

  "Source:":: field gives the source package name.
  "Maintainer:":: gives the name and e-mail address of the person responsible for the package.
  "Build-Depends:":: lists the packages that need to be installed to build the package. They might or might not be needed to actually use the package.
Hi ha algunes caselles requerides, però de moment no s'expliquen.
Al fitxer debian/control, hi han dos paràgrafs.

El primer 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 muntar el paquet. Poden o no ser necessaris per a l'us del paquet.
Line 180: Line 179:
The second paragraph describes the '''binary package''' built from this source. Actually, there can be many binary packages built from the same source.

  "Package:":: is the binary package name. The name might be different from the source package name.
  "Architecture:":: tells which computer architectures the binary package is expected to work on: i386 for 32-bit Intel CPUs, amd64 for 64-bit, armel for ARM processors, and so on. Debian works on about a dozen computer architectures in total, so this architecture support is crucial. The "Architecture:" field can contain names of particular architectures, but usually it contains one of two special values.
El segon paràgraf descriu el '''paquet binari''' muntat des del codi font. Actualment poden haver-hi varis paquets binaris muntats 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, and so on. Debian works on about a dozen computer architectures in total, so this architecture support is crucial. The "Architecture:" field can contain names of particular architectures, but usually it contains one of two special values.

Translation(s): English - Italian



EN PROCÉS DE TRADUCCIÓ--Translation in progress.

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:

  • saps instal·lar paquets binaris;
  • tens coneixements generals de l'us de la línia d'ordres, i coneixes el funcionament d'un editor de text de la teva elecció. (emacs, vim, gedit, kate, etc.);

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 upstream alliberarà una versió del seu programari, i el resultat d'aquest alliberament serà el "el arxivador del codi font upstream " o paquet tar.

Un paquet tar es un fitxer amb extensió .tar.gz o .tgz que crea el desenvolupador 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 crea 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 agut de 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. muntar el paquet de codi font
  5. muntar 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, la numero de versió 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 coincideix 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

Step 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ò tenim que fer una entrada a l'històric, perquè les eines de empaquetament llegeixen certa informació del històric de canvis. El més importatn, llegeixen la versió del paquet.

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

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

This will result in a file like this:

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:

  • La part hithere HA DE SER igual que el nom del paquet font.1.0-1 és la versió. La part 1.0 és la versió d'upstream. La part -1 és la versió de Debian: la primera versió del paquet Debian de la versió d'upstream 1.0. Si el paquet Debian conté un bug, i aquest és reparat, però la versió d'upstream és la mateixa, la propera versió del paquet serà la 1.0-2. La següent 1.0-3, i les següents seguint el patró.

  • UNRELEASED és el destí de pujada. Això indica a l'eina de pujada on s'ha de pujar el paquet binari. UNRELEASED significa que el paquet no està perparat per a ser pujat. Es una bona idea mantenir l'estat com a UNRELEASED , per així evitar pujar el paquet per equivocació.

  • Ignora la part urgency=low per ara. Deixa-ho així.

  • La part (Closes: #XXXXXX) es per a tancar els errors quan el paquet és pujat. Aquesta és la manera típica en la que els errors es tanquen a Debian: quan un paquet que arregla un problema és pujat, l'eina de seguiment d'errors ho detecta, i marca l'error com a tancat. Es pot eliminar (Closes...) . O no, en aquest cas, no importa.

  • L'ultima línia del fitxer changelog indica qui ha fet la aquesta versió del paquet, i quan. La utilitat dch intenta adivinar el nom i la direcció de correu, però es pot configurar amb les dades correctes. Consulta la pàgina del manual dch(1) per als detalls.

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 paquetwho the package maintainer is, 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 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 muntar el paquet. Poden o no ser necessaris per a l'us del paquet.

El segon paràgraf descriu el paquet binari muntat des del codi font. Actualment poden haver-hi varis paquets binaris muntats 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, and so on. Debian works on about a dozen computer architectures in total, so this architecture support is crucial. The "Architecture:" field can contain names of particular architectures, but usually it contains one of two special values.
"any"
(which we see in the example) means that the package can be built for any architecture. In other words, the code has been written portably, so it does not make too many assumptions about the hardware. However, the binary package will still need to be built for each architecture separately.
"all"
means that the same binary package will work on all architectures, without having to be built separately for each. For example, a package consisting only of shell scripts would be "all". Shell scripts work the same everywhere and not need to be compiled.
"Depends:"

field lists the packages that must be installed for the program in the binary package to work. Listing such dependencies manually is tedious, error-prone work. To make this work, the ${shlibs:Depends} magic bit needs to be in there. The other magic stuff is there for debhelper. The {misc:Depends} bit. The shlibs magic is for shared library dependencies, the misc magic is for some stuff debhelper does for other dependencies, you need to add them manually to Depends or Build-Depends and the ${...} magic bits only work in Depends

"Description:"
is the package description. It is meant to be helpful to users.

debian/copyright

It is quite an important file, but for now we will be happy enough with an empty file.

For Debian, this file is used to keep track of the legal, copyright-related information about a package. However, it is not important from a technical point of view. For now, we'll concentrate on the technical aspects. We can get back to debian/copyright later, if there's interest.

debian/rules

It should like this:

#!/usr/bin/make -f
%:
        dh $@
  • <!> Note: The last line should be indented by one TAB character, not by spaces. The file is a makefile, and TAB is what the make command wants

debian/rules can actually be quite a complicated file. However, the dh command in debhelper version 7 has made it possible to keep it this simple in many cases.

debian/source/format

The final file we need is debian/source/format, and it should contain the version number "1.0".

This is the version number for the format of the source package, and even though it happens to be the same as the upstream version, that is just a co-incidence.

Steps 4&5: build the package

Now we can build the package. The command to do that is

debuild -us -uc

There are many commands we could use for this, but this is the one we'll use. If you run the command, you'll get output similar to this:

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

Something went wrong. This is what usually happens. You do your best creating debian/* files, but there's always something that you don't get right. So, the thing that went wrong is this bit:

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

The upstream Makefile is trying to install the compiled program into the wrong location.

There's a couple of things going on here: first is a bit about how Debian packaging works.

When program has been built, and is "installed", it does not get installed into /usr or /usr/local, as usual, but somewhere under the debian/ subdirectory.

We create a subset of the whole filesystem under debian/hithere, and then we put that into the binary package. So the .../debian/hithere/usr/local/bin bit is fine, except that it should not be installing it under usr/local, but directly under usr.

We need to do something to make it install into the right location (debian/hithere/usr/bin).

The right way to fix this is to change debian/rules so that it tells the Makefile where to install things.

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

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

It's again a bit of magic, and to understand it you'll need to know how Makefiles work, and the various stages of a debhelper run.

For now, I'll summarize by saying that there's a command debhelper runs that takes care of installing the upstream files, and this stage is called dh_auto_install.

We need to override this stage, and we do that with a rule in debian/rules called override_dh_auto_install.

The final line in the new debian/rules is a bit of 1970s technology to invoke the upstream Makefile from debian/rules with the right arguments.

Let's try to build things again. It still fails!

  • This time, this is the failing command:

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

We are now trying to install into the right place, but it does not exist. To fix this, we need to tell the packaging tools to create the directory first.

Ideally, the upstream Makefile would create the directory itself, but in this case the upstream developer was too lazy to do so.

The packaging tools (specifically, debhelper) provide a way to do that.

  • Create a file called debian/hithere.dirs, and make it look like this:

usr/bin
usr/share/man/man1

The second line creates the directory for the manual page. We will need it later. Now the build succeeds, but there's still some small problems.

debuild runs the lintian tool, which checks the package that has been built for some common errors. It reports several for this new package:

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.

These should eventually be fixed, but none of them look like they'll be a problem for trying the package. So let's ignore them for now.

Look in the parent directory to find the package that was built.

 # 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

The following command will install the package that you've just built. Do NOT run it on a computer you don't mind breaking.

  • In general, it is best to do package development on a computer that is well backed up, and that you don't mind re-installing if everything goes really badly wrong.

Virtual machines are a good place to do development.

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

And here's the output:

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$ 

How do we test the package? We can run the command.

# hithere

It works! But, it's not perfect. Remember, lintian had things to say, and debian/copyright is empty, etc.

We have a package that works, but it isn't yet of the high quality that is expected of a Debian package.

Conclusions

Once you've built your own packages, you'll eventually want to learn how to set up your apt repository, so your package is easy to install. The best tool for that I know of is reprepro.

For more testing of your package, you may want to look at the tool called piuparts. (I wrote it originally so it is perfect and never has any bugs. er...)

And, finally, if you start making changes to the upstream source, you'll want to learn about the quilt tool.

Other things you might want to read are listed on the http://www.debian.org/devel/ web page.

Questions and Answers

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: that example debian/rules contains only #!make -f , what to do with ./configure , or cmake or scons or .. anything else part?

RESPOSTA: dh has a lot of heuristic, so a package with a ./configure script, or one of the other common ways of building packages, will usually build without any additions

PREGUNTA: heuristics is good, but what if we need to pass --with-something-special to configure or cmake arguments, does heuristics handle those source packages that need ./waf and other tools to build ?

RESPOSTA: I like dapal's answer: <dapal> lilith: using dh7, if you want to pass something to ./configure, just do something like: override_dh_auto_configure <TAB>dh_auto_configure -- --your-params dh has a nice extension/override mechanism that allows you to override particular parts; it is pretty easy to use, once you've read the docs

PREGUNTA: where can we find docs for override stuff of debhelper 7?

RESPOSTA: dh runs a specific sequence of commands to build a package; each command is called dh_something, and each such command can be overridden by having a debian/rules entry called override_dh_something.

Add the --no-act option to the dh command in debian/rules to see what commands it runs; you then have to read the manual page for that command to see if you can configure it (via a file such as debian/hithere.dirs), or if you need to override it.

PREGUNTA: from where do you usually run your commands? inside the dir hithere-1.0 or outside? should there be an outer dir called hithere (without number)

RESPOSTA: I always run the packaging commands in the hithere-1.0 directory, and i usually have a directory above that called hithere but the parent directory is not necessary, it is just neater, so files from different projects don't get mixed up

PREGUNTA: I have a upstream that needs a qmake (uses Qt) before make. Can I add it to debian/rules? How?

RESPOSTA: (by gregoa) debhelper supports qmake since 7.4.12 (so no additional things needed). before that you needed a override_dh_auto_configure :\n\tqmake

PREGUNTA: what is a good workflow to update a package to a new upstream version?

RESPOSTA: ah, I am not sure what is the best workflow for that, but bascially: unpack the upstream source to a new directory, copy the debian/* directory from the old package, update debian/changelog ("dch -v 1.2.3-4") and try to build, and fix anything that is broken. That's not a really good workflow, but for that you will need to learn quilt, and possibly how to use version management with debian packaghing, and that's too big a topic for this session, sorry

PREGUNTA: I have a made debian-package that depends on several other packages. The only thing my package does is actually configure the other packages in a certain way that it fits certain peoples needs. For this it also makes some system critical changes, like activating network routing in kernel and so on.... is there something like a rule what an official package is allowed to do or not? Can such a package get an official package?

RESPOSTA: http://www.debian.org/doc/debian-policy/ is the best written set of rules we have for what an official Debian package is allowed to do, or is required to do.

Debian packages are not allowed to change other package's configs, unless that other package provides a documented interface for it

See also


Note: This page will be a translation from http://wiki.debian.org/IntroDebianPackaging to be done by a Google code-in student.