Dépôts APT locaux en entreprise

Vincent Bernat

Dis­tri­buer de ma­nière ef­fi­cace des lo­gi­ciels sur l’en­semble d’une pla­te­forme peut être ardu. Chaque dis­tri­bu­tion four­nit un ges­tion­naire de pa­quets qui est gé­né­ra­le­ment bien adapté à cette tâche. Dans le cas de De­bian ou d’une dis­tri­bu­tion dé­ri­vée, il s’agit d’APT.

Cer­tains lo­gi­ciels ne sont pas pré­sents dans les dé­pôts of­fi­ciels ou peuvent être dis­po­nibles dans une ver­sion trop an­cienne. La mise en place d’un dé­pôt lo­cal per­met de contour­ner cet écueil.

Ce qui est pré­senté ici a été mis en place pour Dai­ly­mo­tion et a été for­te­ment ins­piré du tra­vail de Ra­phaël Pin­son chez Orange.

Configuration des dépôts locaux#

Les dé­pôts à mettre en place peuvent se clas­ser dans trois ca­tégories :

  1. Les mi­roirs de dis­tri­bu­tions. Ils per­mettent d’éco­no­mi­ser de la bande pas­sante, d’ob­te­nir un meilleur dé­bit et un ac­cès per­ma­nent même lorsque l’ac­cès à In­ter­net est perturbé.

  2. Les dé­pôts mai­sons pour vos propres pa­quets avec la pos­si­bi­lité de pas­ser par une zone de test pour va­li­der les pa­quets sur quelques ma­chines avant de les pous­ser en pro­duction.

  3. Les mi­roirs pour les dé­pôts non of­fi­ciels, tels que des PPA Ubuntu. Pour évi­ter tout chan­ge­ment in­at­tendu, de tels dé­pôts sont aussi do­tés d’une zone de test et d’une zone de pro­duction.

Avant de conti­nuer, il est im­por­tant de s’ac­cor­der sur la ter­mi­no­lo­gie à em­ployer. Exa­mi­nons une ligne is­sue de mon /etc/apt/sources.list:

deb http://ftp.debian.org/debian/ unstable main contrib non-free

Dans cet exemple, http://ftp.debian.org/debian/ est un dé­pôt et unstable est une dis­tri­bu­tion. Une dis­tri­bu­tion est di­vi­sée en un cer­tain nombre de com­po­sants. Nous en avons ici trois : main, contrib et non-free.

La mise en place des dif­fé­rents dé­pôts se fera avec le lo­gi­ciel re­pre­pro. Ce n’est pas la seule so­lu­tion dis­po­nible mais il est à la fois plu­tôt ver­sa­tile et simple à mettre en place. re­pre­pro ne gère qu’un seul dé­pôt. Le pre­mier choix à ef­fec­tuer est donc de sa­voir com­ment ré­par­tir les pa­quets dans les dé­pôts, les dis­tri­bu­tions et les com­posants.

Mise à jour (06.2019)

aptly est une al­ter­na­tive à re­pre­pro. Il gère plu­sieurs dé­pôts. Il pro­pose une API HTTP et il peut conser­ver plu­sieurs ver­sions d’un même pa­quet. Pour un mi­roir com­plet d’une dis­tri­bu­tion, re­pre­pro reste plus per­for­mant, mais pour le reste, je vous conseille d’uti­li­ser aptly.

Voici quelques billes pour choisir :

  • Un dé­pôt ne peut pas conte­nir deux pa­quets iden­tiques (même nom, même ver­sion, même ar­chi­tecture).
  • À l’in­té­rieur d’un com­po­sant, il n’est pos­sible d’avoir qu’une seule ver­sion d’un paquet.
  • Ha­bi­tuel­le­ment, une dis­tri­bu­tion est un sous-en­semble des ver­sions tan­dis qu’un com­po­sant est un sous-en­semble des pa­quets. Par exemple, dans De­bian, la dis­tri­bu­tion unstable per­met d’ob­te­nir des pa­quets dans des ver­sions très ré­centes tan­dis que le com­po­sant main per­met de se li­mi­ter aux pa­quets res­pec­tant la DFSG.

En par­tant sur plu­sieurs dé­pôts, il fau­dra gé­rer plu­sieurs ins­tances de re­pre­pro et la co­pie entre deux ins­tances se fait ma­nuel­le­ment. À Dai­ly­mo­tion, nous sommes par­tis sur un seul dé­pôt, mais il au­rait été pos­sible de par­tir sur trois dépôts :

  • un pour les mi­roirs de dis­tri­butions,
  • un pour les pa­quets maisons,
  • un pour les mi­roirs de dé­pôts tiers.

Voici ce que nous al­lons mettre en place :

Local APT repository
Un dépôt avec trois distributions comprenant également une zone de test.

Mise en place#

La pre­mière étape est de créer un uti­li­sa­teur pour tra­vailler sur les dépôts :

$ adduser --system --disabled-password --disabled-login \
>         --home /srv/packages \
>         --group reprepro

Toutes les opé­ra­tions qui suivent doivent uti­li­ser ex­clu­si­ve­ment cet uti­li­sa­teur. Chaque dé­pôt aura son propre ré­per­toire dans le­quel on trou­vera les sous-ré­per­toires suivants :

  • conf/ qui contient les fi­chiers de confi­guration,
  • gpg/ qui contient les fi­chiers per­met­tant de si­gner et au­then­ti­fier les dé­pôts avec GPG1,
  • logs/ qui contient les journaux,
  • www/ qui contient les fi­chiers du dé­pôt à rendre vi­sible par un quel­conque ser­veur web.

Voici le contenu de conf/options :

outdir +b/www
logdir +b/logs
gnupghome +b/gpg

Créons la clé GPG pour si­gner le dépôt :

$ GNUPGHOME=gpg gpg --gen-key
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 10y
Key expires at mer. 08 nov. 2023 22:30:58 CET
Is this correct? (y/N) y

Real name: Dailymotion Archive Automatic Signing Key
Email address: the-it-operations@dailymotion.com
Comment:
[…]

Un mot de passe vide per­met à re­pre­pro de tour­ner sans in­ter­ven­tion de l’uti­li­sa­teur (no­tam­ment pour les mises à jour noc­turnes). La clé pu­blique de­vra être dis­tri­buée pour per­mettre à APT de vé­ri­fier les si­gna­tures de l’ar­chive. Une fa­çon com­mode de faire est de la pla­cer dans un paquet.

Miroir local d’une distribution officielle#

Com­men­çons par mettre en place un mi­roir pour Ubuntu Pre­cise. Nous avons be­soin de faire deux choses :

  1. Confi­gu­rer une nou­velle dis­tri­bu­tion dans le fi­chier conf/distributions.
  2. Confi­gu­rer les sources dans le fi­chier conf/updates.

Ajou­tons ce bloc dans conf/distributions:

# Ubuntu Precise
Origin: Ubuntu
Label: Ubuntu
Suite: precise
Version: 12.04
Codename: precise
Architectures: i386 amd64
Components: main restricted universe multiverse
UDebComponents: main restricted universe multiverse
Description: Ubuntu Precise 12.04 (with updates and security)
Contents: .gz .bz2
UDebIndices: Packages Release . .gz
Tracking: minimal
Update: - ubuntu-precise ubuntu-precise-updates ubuntu-precise-security
SignWith: yes

Il dé­fi­nit la dis­tri­bu­tion precise dans notre dé­pôt. Elle contient quatre com­po­sants : main, restricted, universe et multiverse (comme la dis­tri­bu­tion pré­sente dans les dé­pôts of­ficiels).

La ligne Update com­mence par un ti­ret. Cela si­gni­fie que re­pre­pro va mar­quer tous les pa­quets comme à ef­fa­cer avant d’ap­pli­quer les mises à jour in­di­quées. Les pa­quets sup­pri­més de la dis­tri­bu­tion of­fi­cielle ne se­ront donc pas conser­vés dans notre mi­roir. Dans conf/updates, nous dé­fi­nis­sons les sources :

# Ubuntu Precise
Name: ubuntu-precise
Method: http://fr.archive.ubuntu.com/ubuntu
Fallback: http://de.archive.ubuntu.com/ubuntu
Suite: precise
Components: main main multiverse restricted universe
UDebComponents: main restricted universe multiverse
Architectures: amd64 i386
VerifyRelease: 437D05B5
GetInRelease: no

# Ubuntu Precise Updates
Name: ubuntu-precise-updates
Method: http://fr.archive.ubuntu.com/ubuntu
Fallback: http://de.archive.ubuntu.com/ubuntu
Suite: precise-updates
Components: main restricted universe multiverse
UDebComponents: main restricted universe multiverse
Architectures: amd64 i386
VerifyRelease: 437D05B5
GetInRelease: no

# Ubuntu Precise Security
Name: ubuntu-precise-security
Method: http://fr.archive.ubuntu.com/ubuntu
Fallback: http://de.archive.ubuntu.com/ubuntu
Suite: precise-security
Components: main restricted universe multiverse
UDebComponents: main restricted universe multiverse
Architectures: amd64 i386
VerifyRelease: 437D05B5
GetInRelease: no

Les lignes VerifyRelease in­diquent les em­preintes des clefs GPG à uti­li­ser pour vé­ri­fier la si­gna­ture des dé­pôts dis­tants. Il faut im­por­ter la clé en ques­tion dans l’an­neau local :

$ gpg --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg \
>     --export 437D05B5 | GNUPGHOME=gpg gpg --import

Un autre point im­por­tant est le fait que nous avons fu­sionné trois dis­tri­bu­tions (precise, precise-updates et precise-security) dans une seule dis­tri­bu­tion (precise) dans notre dé­pôt lo­cal. Cela peut pro­vo­quer des dif­fi­cul­tés avec les ou­tils, tels que le De­bian Ins­tal­ler2, qui s’at­tendent à trou­ver les trois dis­tri­bu­tions classiques.

Il est en­suite pos­sible de lan­cer re­pre­pro pour mettre à jour le miroir :

$ reprepro update

Cela prend un cer­tain temps la pre­mière fois. re­pre­pro n’est pas la so­lu­tion la plus ef­fi­cace pour mettre en place un mi­roir, mais sa prise en main est simple et il est par­ti­cu­liè­re­ment fiable.

Dépôt maison#

Pas­sons au dé­pôt pour les pa­quets mai­sons. Pour chaque dis­tri­bu­tion of­fi­cielle (telle que precise), nous met­tons en place deux dis­tri­butions :

  • precise-staging contient les pa­quets en cours de test.
  • precise-prod contient les pa­quets tes­tés is­sus de precise-staging.

Dans cette or­ga­ni­sa­tion, les pa­quets sont in­tro­duits dans precise-staging où ils peuvent être tes­tés sur quelques ser­veurs avant d’être co­piés dans precise-prod pour être dis­po­nibles sur l’en­semble de la pla­te­forme. La dé­cla­ra­tion dans conf/distributions se fait ainsi :

# Dailymotion Precise packages (staging)
Origin: Dailymotion # ❸
Label: dm-staging   # ❸
Suite: precise-staging
Codename: precise-staging
Architectures: i386 amd64 source
Components: main role/dns role/database role/web # ❶
Description: Dailymotion Precise staging repository
Contents: .gz .bz2
Tracking: keep
SignWith: yes
NotAutomatic: yes # ❷
Log: packages.dm-precise-staging.log
 --type=dsc email-changes

# Dailymotion Precise packages (prod)
Origin: Dailymotion # ❸
Label: dm-prod      # ❸
Suite: precise-prod
Codename: precise-prod
Architectures: i386 amd64 source
Components: main role/dns role/database role/web # ❶
Description: Dailymotion Precise prod repository
Contents: .gz .bz2
Tracking: keep
SignWith: yes
Log: packages.dm-precise-prod.log

No­tez d’abord l’uti­li­sa­tion de plu­sieurs com­po­sants (en ❶) :

  • main contien­dra les pa­quets gé­né­riques. Un pa­quet placé dans main doit pou­voir être uti­lisé sur n’im­porte quel serveur.
  • role/* sont des com­po­sants dé­diés à un sous-en­semble de la pla­te­forme. Par exemple, dans role/dns, on trou­vera des ver­sions mo­di­fiées de BIND.

La dis­tri­bu­tion de test uti­lise le dra­peau NotAutomatic (en ❷) qui in­dique au ges­tion­naire de pa­quets de ne pas ins­tal­ler ces pa­quets à moins d’une re­quête ex­presse de l’uti­li­sa­teur. Juste au-des­sous, quand un nou­veau fi­chier dsc est reçu, le script email-changes est exé­cuté. Il doit se trou­ver dans le ré­per­toire conf/.

Les lignes Origin et Label (en ❸) sont par­ti­cu­liè­re­ment im­por­tantes car elles se­ront uti­li­sées pour dé­ter­mi­ner la po­li­tique d’ins­tal­la­tion des pa­quets. Pre­nons ce fi­chier /etc/apt/sources.list :

# Ubuntu packages
deb http://packages.dm.gg/dailymotion precise main restricted universe multiverse

# Dailymotion packages
deb http://packages.dm.gg/dailymotion precise-prod    main role/dns
deb http://packages.dm.gg/dailymotion precise-staging main role/dns

Tous les ser­veurs peuvent uti­li­ser la dis­tri­bu­tion precise-staging. Il est es­sen­tiel de ne pas ins­tal­ler par er­reur des pa­quets de cette dis­tri­bu­tion. Le dra­peau NotAutomatic est une pre­mière sé­cu­rité. Nous y ajou­tons ce fi­chier /etc/apt/preferences :

Explanation: Dailymotion packages of a specific component should be more preferred
Package: *
Pin: release o=Dailymotion, l=dm-prod, c=role/*
Pin-Priority: 950

Explanation: Dailymotion packages should be preferred
Package: *
Pin: release o=Dailymotion, l=dm-prod
Pin-Priority: 900

Explanation: staging should never be preferred
Package: *
Pin: release o=Dailymotion, l=dm-staging
Pin-Priority: -100

Par dé­faut, les pa­quets ont une prio­rité de 500. En uti­li­sant une prio­rité de -100 pour les pa­quets en pro­ve­nance de la dis­tri­bu­tion de test, nous nous as­su­rons qu’ils ne peuvent pas être ins­tal­lés du tout. C’est une contrainte plus forte que l’uti­li­sa­tion de NotAutomatic qui place la prio­rité à 1. Nous fa­vo­ri­sons les pa­quets se trou­vant dans le dé­pôt mai­son par rap­port aux pa­quets of­fi­ciels en leur af­fec­tant une prio­rité de 900 (voire 950 pour les pa­quets qui se trouvent dans un com­po­sant type rôle).

La sec­tion “How APT In­ter­prets Prio­ri­ties” de la page de ma­nuel apt_preferences(5) donne plus de dé­tails. Il faut gar­der en tête que les ver­sions ne sont uti­li­sées qu’à prio­rité égale. La com­mande apt-cache policy per­met de vé­ri­fier que tout fonc­tionne comme attendu :

$ apt-cache policy php5-memcache
  Installed: 3.0.8-1~precise2~dm1
  Candidate: 3.0.8-1~precise2~dm1
  Version table:
 *** 3.0.8-1~precise2~dm1 0
        950 http://packages.dm.gg/dailymotion/ precise-prod/role/web amd64 Packages
        100 /var/lib/dpkg/status
     3.0.8-1~precise1~dm4 0
        900 http://packages.dm.gg/dailymotion/ precise-prod/main amd64 Packages
       -100 http://packages.dm.gg/dailymotion/ precise-staging/main amd64 Packages
     3.0.6-1 0
        500 http://packages.dm.gg/dailymotion/ precise/universe amd64 Packages

Pour ins­tal­ler un pa­quet en pro­ve­nance de la dis­tri­bu­tion de test, il suf­fit d’in­vo­quer apt-get avec l’op­tion -t precise-staging qui aug­mente la prio­rité de cette dis­tri­bu­tion à 990.

Une fois le pa­quet testé sur quelques ser­veurs, il est pos­sible de le co­pier vers la dis­tri­bu­tion de pro­duction :

$ reprepro -C main copysrc precise-prod precise-staging wackadoodle

Miroir local de dépôts tiers#

Par­fois, plu­tôt que de re­cons­truire un pa­quet, il est pré­fé­rable de le prendre di­rec­te­ment sur un dé­pôt tiers. Un exemple cou­rant est les dé­pôts mis en place par les construc­teurs. Comme pour la mise en place d’un mi­roir d’une dis­tri­bu­tion of­fi­cielle, il y a deux étapes : dé­fi­ni­tion de la dis­tri­bu­tion et dé­cla­ra­tion des sources.

Chaque mi­roir va se trou­ver dans les mêmes dis­tri­bu­tions que nos pa­quets mai­sons mais ils iront dans un com­po­sant dé­dié. Cela nous per­met d’uti­li­ser la même or­ga­ni­sa­tion que pour les pa­quets lo­caux : ils ap­pa­raî­tront dans la dis­tri­bu­tion de test avant d’être ma­nuel­le­ment co­piés, après va­li­da­tion, dans la dis­tri­bu­tion de pro­duction.

La pre­mière étape consiste à ajou­ter le com­po­sant et la ligne Update ap­pro­priée dans le fi­chier conf/distributions :

Origin: Dailymotion
Label: dm-staging
Suite: precise-staging
Components: main role/dns role/database role/web vendor/hp
Update: hp
# […]

Origin: Dailymotion
Label: dm-prod
Suite: precise-prod
Components: main role/dns role/database role/web vendor/hp
# […]

Le com­po­sant vendor/hp a été ajouté aux deux dis­tri­bu­tions mais seule la dis­tri­bu­tion de test a une ligne Update. La dis­tri­bu­tion de pro­duc­tion ob­tien­dra les pa­quets par co­pie manuelle.

La source des pa­quets est dé­cla­rée dans le fi­chier conf/updates :

# HP repository
Name: hp
Method: http://downloads.linux.hp.com/SDR/downloads/ManagementComponentPack/
Suite: precise/current
Components: non-free>vendor/hp
Architectures: i386 amd64
VerifyRelease: 2689B887
GetInRelease: no

N’ou­bliez pas de ra­jou­ter la clé GPG cor­res­pon­dante dans l’an­neau lo­cal. À no­ter une fonc­tion­na­lité par­ti­cu­liè­re­ment in­té­res­sante de re­pre­pro qui per­met de co­pier le com­po­sant non-free dans le com­po­sant vendor/hp.

Construction des paquets Debian#

La confi­gu­ra­tion de re­pre­pro est dé­sor­mais ter­mi­née. Com­ment construire les pa­quets à pla­cer dans la dis­tri­bu­tion de test ?

Se­lon le temps que vous sou­hai­tez ac­cor­der à cette ac­ti­vité, il y a plu­sieurs pos­si­bilités :

  1. Construire un pa­quet source en ajou­tant un ré­per­toire debian/. C’est la fa­çon clas­sique. Il est pos­sible de par­tir de zéro ou de prendre un pa­quet exis­tant dans une dis­tri­bu­tion plus ré­cente ou un ré­tro­por­tage d’un dé­pôt non officiel.

  2. Uti­li­ser un ou­til qui va créer un pa­quet bi­naire à par­tir d’un ré­per­toire, tel que fpm. Un tel ou­til va mi­ni­mi­ser le bou­lot à ef­fec­tuer pour construire un pa­quet et peut même em­pa­que­ter au­to­ma­ti­que­ment cer­tains types de lo­giciels.

Il n’y a pas de so­lu­tion uni­ver­selle. La pre­mière ap­proche est plus chro­no­phage mais dis­pose des avan­tages suivants :

  • Les sources res­tent dis­po­nibles dans le dé­pôt. Si vous avez be­soin de re­cons­truire un pa­quet en ur­gence pour cor­ri­ger un pro­blème, il n’est pas né­ces­saire de par­tir à la re­cherche des sources qui peuvent être tem­po­rai­re­ment in­dis­po­nibles. Bien sûr, cela n’est va­lable que pour les pa­quets qui ne té­lé­chargent pas les dé­pen­dances de­puis Internet.

  • La re­cette de construc­tion est conser­vée3 dans le dé­pôt. Si quelqu’un ac­tive telle op­tion et re­cons­truit le pa­quet, cette op­tion ne sera pas per­due lorsqu’une autre per­sonne re­cons­truira le pa­quet. Ces chan­ge­ments sont do­cu­men­tés dans le fi­chier debian/changelog. De plus, un sys­tème de ges­tion des ver­sions peut être uti­lisé pour gar­der une trace pré­cise des chan­ge­ments liés à l’em­pa­quetage.

  • Le pa­quet ob­tenu peut en­suite être pro­posé à l’in­clu­sion dans De­bian. Cela ren­dra ser­vice à de nom­breuses autres personnes.

Mise à jour (10.2017)

Je pré­sente une ap­proche al­ter­na­tive pour créer des pa­quets De­bian sans trop d’ef­fort dans « Pe­tit traité em­pi­rique de l’em­pa­que­tage Debian ».

Compilation#

pbuil­der est uti­lisé pour la com­pi­la­tion au­to­ma­tique des pa­quets4. Sa mise en place est re­la­ti­ve­ment simple. Voici le fi­chier pbuilderrc utilisé :

DISTRIBUTION=$DIST
NAME="$DIST-$ARCH"
MIRRORSITE=http://packages.dm.gg/dailymotion
COMPONENTS=("main" "restricted" "universe" "multiverse")
OTHERMIRROR="deb http://packages.dm.gg/dailymotion ${DIST}-staging main"
HOOKDIR=/etc/pbuilder/hooks.d
BASE=/var/cache/pbuilder/dailymotion
BASETGZ=$BASE/$NAME/base.tgz
BUILDRESULT=$BASE/$NAME/results/
APTCACHE=$BASE/$NAME/aptcache/
DEBBUILDOPTS="-sa"
KEYRING="/usr/share/keyrings/dailymotion-archive.keyring.gpg"
DEBOOTSTRAPOPTS=("--arch" "$ARCH" "--variant=buildd" "${DEBOOTSTRAPOPTS[@]}" "--keyring=$KEYRING")
APTKEYRINGS=("$KEYRING")
EXTRAPACKAGES=("dailymotion-archive-keyring")

pbuilder doit être in­vo­qué avec les va­riables d’en­vi­ron­ne­ment DIST, ARCH et (op­tion­nel­le­ment) ROLE. La mise en place de chaque en­vi­ron­ne­ment s’ef­fec­tue ainsi :

for ARCH in i386 amd64; do
  for DIST in precise; do
    export ARCH
    export DIST
    pbuilder --create
  done
done

Concer­nant les rôles, un cro­chet de type D per­met d’ajou­ter les sources ap­pro­priées avant la com­pilation :

#!/bin/bash
[ -z "$ROLE" ] || {
  cat >> /etc/apt/sources.list <<EOF
deb http://packages.dm.gg/dailymotion ${DIST}-staging role/${ROLE}
EOF
}

apt-get update

Un cro­chet de type E per­met de s’as­su­rer que les pa­quets de la dis­tri­bu­tion de test sont prio­ri­tai­re­ment uti­li­sés pour la construction :

#!/bin/bash

cat > /etc/apt/preferences <<EOF
Explanation: Dailymotion packages are of higher priority
Package: *
Pin: release o=Dailymotion
Pin-Priority: 900
EOF

En­fin, un cro­chet de type C per­met d’ob­te­nir un shell en cas d’er­reur, ce qui est pra­tique pour cor­ri­ger un problème :

#!/bin/bash
apt-get install -y --force-yes vim less
cd /tmp/buildd/*/debian/..
/bin/bash < /dev/tty > /dev/tty 2> /dev/tty

Une com­pi­la­tion peut en­suite être lan­cée avec la commande :

$ ARCH=amd64 DIST=precise ROLE=web pbuilder \
>         --build somepackage.dsc

Numérotation des versions#

Afin d’évi­ter des règles trop com­plexes pour les ver­sions, tout pa­quet est traité comme étant un ré­tro­por­tage. Le schéma uti­lisé est le sui­vant : X-Y~preciseZ+dmW.

  • X est la ver­sion amont5.

  • Y est la ver­sion De­bian. S’il n’y a pas de ver­sion De­bian, mettre 0.

  • Z est la ver­sion du back­port dans Ubuntu. S’il n’existe pas, mettre 0.

  • W est notre ver­sion du pa­quet. Il est in­cré­menté à chaque chan­ge­ment dans le pa­quet. C’est le seul nu­méro que nous contrô­lons. Tous les autres dé­pendent d’une en­tité en amont.

Sup­po­sons que l’on dé­sire ré­tro­por­ter le pa­quet wackadoodle. Il est dis­po­nible dans une Ubuntu plus ré­cente en ver­sion 1.4-3. La pre­mière ver­sion du pa­quet aura pour ver­sion 1.4-3~precise0+dm1. Après un chan­ge­ment dans le fi­chier debian/rules, nous ob­te­nons la ver­sion 1.4-3~precise0+dm2. En amont, une ver­sion 1.5 de­vient dis­po­nible. Elle n’est dis­po­nible ni dans Ubuntu, ni dans De­bian. Le nu­méro de ver­sion du pa­quet sera alors 1.5-0~precise0+dm1.

Quelques se­maines plus tard, le pa­quet ar­rive chez Ubuntu dans la ver­sion 1.5-3ubuntu1. Vous y ap­pli­quez des chan­ge­ments pour ob­te­nir la ver­sion 1.5-3ubuntu1~precise0+dm1.

Une conven­tion com­pa­tible avec les pra­tiques de De­bian concer­nant les ré­tro­por­tages est : X-Y~bpo70+Z~dm+W.

Envoi#

Pour in­té­grer un pa­quet dans le dé­pôt, les étapes clas­siques sont les suivantes :

  1. Le pa­quet source est placé dans un ré­per­toire incoming/.
  2. re­pre­pro re­marque le pa­quet source, vé­ri­fie sa va­li­dité (si­gna­ture, dis­tri­bu­tion) et le place dans l’archive.
  3. Le sys­tème de com­pi­la­tion re­marque un nou­veau pa­quet source à construire et lance la com­pi­la­tion de celui-ci.
  4. Une fois les pa­quets bi­naires construits, ils sont éga­le­ment pla­cés dans le ré­per­toire incoming/.
  5. re­pre­pro dé­tecte les pa­quets bi­naires et les in­tègre dans l’archive.

Cette fa­çon de faire a le désa­van­tage d’être dif­fi­cile à suivre pour l’uti­li­sa­teur. Une al­ter­na­tive est de conce­voir un script de construc­tion exé­cu­tant chaque tâche de ma­nière syn­chrone et per­met­tant ainsi à l’uti­li­sa­teur de suivre son ter­mi­nal le bon dé­rou­le­ment des opé­ra­tions. Ce script s’oc­cupe éga­le­ment d’in­clure les pa­quets fi­naux dans l’archive :

$ reprepro -C main include precise-staging \
>      wackadoodle_1.4-3~precise0+dm4_amd64.changes

Voilà !