Table des matières
NMU
)
testing
Ce chapitre contient des informations relatives à la création, l'envoi, la maintenance et le portage des paquets.
Si vous voulez créer un nouveau paquet pour la distribution Debian, vous
devriez commencer par consulter la liste des paquets
en souffrance et paquets souhaités (« Work-Needing and Prospective
Packages
» ou WNPP
). Vous pourrez ainsi
vérifier que personne ne travaille déjà sur ce paquet et éviter un travail
en double. Consultez aussi cette page si vous voulez en savoir plus.
Supposons que personne ne travaille sur le paquet que vous visez, vous devez
alors envoyer un rapport de bogue (voir Section 7.1, « Signalement de bogues »)
concernant le pseudopaquet wnpp
. Ce
courrier devra décrire le paquet que vous projetez de créer, la licence de
ce paquet et l'URL à laquelle le code source peut être téléchargé. Cette
liste n'est pas limitative.
Le sujet du rapport de bogue pour déclarer votre intention d'empaqueter
(« Intent To Package
» ou ITP
) devra
être ITP:
, en remplaçant
NomDuPaquet
--
description courte
NomDuPaquet
par le nom du paquet. La gravité du
bogue sera wishlist
. Si vous le jugez nécessaire, envoyez
une copie à <debian-devel@lists.debian.org>
en mettant cette adresse dans le champ
X-Debbugs-CC
de l'en-tête du message. N'utilisez pas le
champ CC
sinon le sujet du message ne contiendrait pas le
numéro du bogue. Si vous empaquetez tellement de paquets (plus de dix) que
les signaler sur la liste de diffusion soit trop perturbant, envoyez plutôt
un résumé sur la liste debian-devel
après avoir rempli
les rapports de bogue. Cela informera les autres développeurs de l'arrivée
de nouveaux paquets et permettra une relecture des description et nom de
paquet.
Veuillez ajouter « Closes:
#
» au journal de modification
(nnnnn
changelog
) du nouveau paquet. Cette indication
provoquera la fermeture automatique du rapport de bogue à l'installation du
nouveau paquet dans l'archive (voir Section 5.8.4, « Fermeture des rapports de bogue lors des mises à jour »).
Si vous jugez nécessaire d'ajouter des explications pour les administrateurs
de la file d'attente de nouveaux paquets (NEW
), veuillez
les ajouter au fichier changelog
, envoyer à
<ftpmaster@debian.org>
une réponse au message reçu en tant que responsable suite
à votre envoi de paquet, ou une réponse au message de rejet si vous envoyez
à nouveau le paquet.
Lors de la fermeture de bogues de sécurité, indiquez les numéros CVE en plus
de « Closes: #
». Cela
permet à l'équipe de sécurité de suivre les failles. Si un envoi est
effectué pour corriger le bogue avant que l'identifiant d'alerte soit connu,
il est conseillé de modifier la mention existante du fichier
nnnnn
changelog
lors d'un envoi suivant. Même dans ce cas,
veuillez inclure toutes les indications disponibles sur les origines de la
situation dans la première entrée de changelog
.
Les responsables sont priés d'annoncer leurs intentions pour plusieurs raisons :
afin d'être informés si quelqu'un travaille déjà sur le paquet, et pour permettre à d'autres membres de la liste de partager leur expérience ;
si d'autres personnes envisagent de travailler sur le même paquet, elles apprendront qu'il existe un volontaire et pourront proposer de partager le travail ;
cela permet aux autres responsables d'en apprendre plus sur le nouveau
paquet que la description courte et la formule consacrée du journal de
modification « Initial release
» (publication initiale)
envoyée sur <debian-devel-changes@lists.debian.org>
;
cette information est utile aux utilisateurs d'unstable
qui sont les premiers testeurs. Ces personnes devraient être incitées à
essayer le nouveau paquet ;
ces annonces donnent aux responsables et autres personnes intéressées une meilleure idée des évolutions et des nouveautés du projet.
Veuillez consulter https://ftp-master.debian.org/REJECT-FAQ.html pour les raisons courantes de rejet des nouveaux paquets.
Les modifications apportées au paquet doivent être consignées dans le
fichier debian/changelog
. Ces notes doivent donner une
description concise des changements, expliquer les raisons de ceux-ci (si ce
n'est pas clair) et indiquer quels rapports de bogue ont été clos. Il faut
aussi indiquer quand le paquet a été terminé. Ce fichier sera installé dans
/usr/share/doc/
ou
paquet
/changelog.Debian.gz/usr/share/doc/
pour un paquet natif.
paquet
/changelog.gz
Le fichier debian/changelog
a une structure précise
comportant différents champs. Le champ distribution
est
décrit en Section 5.5, « Choix de distribution ». Plus d'informations sur la
structure de ce fichier sont disponibles dans la section
« debian/changelog
» de la Charte Debian
(« Debian Policy
»).
Certaines indications du fichier changelog
peuvent
provoquer la fermeture automatique des rapports de bogue au moment où le
paquet est installé dans l'archive. Voir Section 5.8.4, « Fermeture des rapports de bogue lors des mises à jour ».
Par convention, quand un paquet contient une nouvelle version amont, le
fichier changelog
comporte une ligne qui ressemble à :
* New upstream release.
Certains outils peuvent aider à éditer et finaliser le fichier
changelog
— voir Section A.6.1, « devscripts
» et Section A.6.5, « dpkg-dev-el
».
Voir aussi Section 6.3, « Meilleures pratiques pour debian/changelog
».
Avant d'envoyer un paquet, il faut effectuer quelques tests essentiels. Les opérations suivantes (une ancienne version du paquet est parfois nécessaire) devraient au moins être effectuées :
installer le paquet et vérifier que le logiciel fonctionne. Si le paquet existait déjà dans une version plus ancienne, faire une mise à niveau ;
exécuter lintian sur le paquet. Il est possible
d'exécuter lintian comme suit : lintian -v
. Cette commande
provoquera une vérification des paquets source et binaire. En cas de
difficultés pour comprendre les messages de retour, utiliser l'option
paquet-version
.changes-i
de lintian. Cette option rendra
lintian beaucoup plus explicite dans la description des
problèmes.
En principe, un paquet pour lequel lintian renvoie des
erreurs (elles commencent par E
) ne devrait
jamais être envoyé.
Pour en savoir plus sur lintian, voir Section A.2.1, « lintian
» ;
facultativement exécuter debdiff (voir Section A.2.2, « debdiff ») pour analyser les modifications depuis une ancienne version si celle-ci existe ;
revenir à la version précédente du paquet (si elle existe) — cela permet de
tester les scripts postrm
et
prerm
;
retirer le paquet et le réinstaller à nouveau ;
copier le paquet source dans un répertoire différent puis tenter de le
décompresser et de le reconstruire. Le but est de vérifier que la
construction n'utilise pas de fichiers en dehors de ceux du paquet ou des
permissions non préservées sur les fichiers contenus dans le fichier
.diff.gz
.
Il existe deux types de paquets source Debian :
les paquets natifs (« native
») pour lesquels il n'y a
pas de distinction entre les sources d'origine et les correctifs appliqués
pour Debian ;
les paquets (plus courants) avec au moins une archive, contenant les sources d'origine, accompagnée d'un fichier, contenant les modifications pour Debian.
Pour les paquets natifs, le paquet source comprend un fichier de contrôle
source Debian (.dsc
) et l'archive source
(.tar.{gz,bz2,xz}
). Un paquet source d'un paquet non
natif comprend un fichier de contrôle source Debian, l'archive source
d'origine (.orig.tar.{gz,bz2,xz}
) et les modifications
Debian (.diff.gz
pour le format source « 1.0 » ou
.debian.tar.{gz,bz2,xz}
pour le format source
« 3.0 (quilt) »).
Avec le format « 1.0 », le paquet est soit natif, soit non déterminé par
dpkg-source au moment de la construction. Il est
dorénavant recommandé de déterminer explicitement le format source en
écrivant « 3.0 (quilt) » ou « 3.0 (native) » dans
debian/source/format
. La suite de cette partie ne
traite que les paquets non natifs.
The first time a version is uploaded that corresponds to a particular
upstream version, the original source tar file must be uploaded and included
in the .changes
file. Subsequently, this very same tar
file should be used to build the new diffs and .dsc
files, and will not need to be re-uploaded.
Par défaut, dpkg-genchanges et
dpkg-buildpackage incluront le fichier
tar
amont si et seulement si la précédente modification
de changelog
mentionne une version amont différente de
la précédente. Ce comportement peut être modifié en utilisant
-sa
pour l'inclure systématiquement ou
-sd
pour ne jamais l'inclure.
Si la mise à jour ne contient pas le fichier tar
des
sources d'origine, dpkg-source doit
utiliser le même fichier tar
que celui déjà présent
dans l'archive pour construire les fichiers .dsc
et
diff
envoyés.
Please notice that, in non-native packages, permissions on files that are
not present in the *.orig.tar.{gz,bz2,xz}
will not be
preserved, as diff does not store file permissions in the patch. However,
when using source format “3.0 (quilt)”, permissions of files inside the
debian
directory are preserved since they are stored in
a tar archive.
Chaque envoi doit indiquer à quelle distribution le paquet est destiné. Le
processus de construction de paquet extrait cette information à partir de la
première ligne du fichier debian/changelog
et la place
dans le champ Distribution
du fichier
.changes
.
Packages are normally uploaded into unstable
. Uploads to
unstable
or experimental
should use
these suite names in the changelog entry; uploads for other supported suites
should use the suite codenames, as they avoid any ambiguity.
En fait, il y a d'autres distributions possibles :
nomdecode
-security
, consultez
Section 5.8.5, « Gestion des bogues de sécurité » pour plus d'informations sur celles-ci.
Il n'est pas possible d'envoyer un paquet dans plusieurs distributions en même temps.
Envoyer un paquet pour la distribution stable
signifie
que le paquet sera dirigé vers la file d'attente
proposed-updates-new
pour être revu par les responsables
de la publication stable
. Une fois accepté, le paquet
sera installé dans le répertoire
stable-proposed-updates
de l'archive Debian. Il sera
ensuite ajouté à stable
lors de la prochaine mise à jour
de la distribution.
To ensure that your upload will be accepted, you should discuss the changes
with the stable release team before you upload. For that, file a bug against
the release.debian.org
pseudo-package using reportbug, including the patch you
want to apply to the package version currently in
stable
. The patch should be a source
debdiff (see Section A.2.2, « debdiff ») against the
current version in stable
. The changelog entry should be
against the stable
distribution
(e.g. `stretch') and should be detailed, including
Closes
statements for bugs that are fixed by the upload.
Une mise à jour de paquet pour la distribution stable
requiert des soins supplémentaires. Un paquet de cette distribution ne
devrait être mis à jour que dans les cas suivants :
un problème fonctionnel vraiment critique ;
un paquet devenu non installable ;
un paquet indisponible pour une architecture.
In the past, uploads to stable
were used to address
security problems as well. However, this practice is deprecated, as uploads
used for Debian security advisories (DSAs) are automatically copied to the
appropriate proposed-updates
archive when the advisory
is released. See Section 5.8.5, « Gestion des bogues de sécurité » for detailed information on
handling security problems. If the security team deems the problem to be too
benign to be fixed through a DSA
, the stable release
managers are usually willing to include your fix nonetheless in a regular
upload to stable
.
Il est fortement déconseillé de changer quoi que ce soit de non important car même une modification triviale peut provoquer un bogue.
Les paquets à destination de stable
doivent être compilés
sur un système qui tourne sous stable
, afin de limiter
les dépendances aux bibliothèques (et autres paquets) disponibles dans
stable
; par exemple, un paquet pour
stable
qui dépend de bibliothèques uniquement disponibles
dans unstable
sera rejeté. Modifier les dépendances
d'autres paquets (en semant la pagaille avec les champs
Provides
ou les fichiers shlibs
), au
risque de rendre d'autres paquets impossibles à installer, est fortement
déconseillé.
Les mises à jour de la distribution oldstable
sont
possibles tant qu'elle n'a pas été archivée. Les mêmes règles que pour
stable
s'appliquent.
Veuillez consulter les informations de la section
relative à testing
pour plus de détails.
To upload a package, you should upload the files (including the signed
changes and dsc file) with anonymous ftp to
ftp.upload.debian.org
in the directory /pub/UploadQueue/. To get
the files processed there, they need to be signed with a key in the Debian
Developers keyring or the Debian Maintainers keyring (see https://wiki.debian.org/DebianMaintainer).
Attention, il est préférable de transférer le fichier
changes
en dernier. Dans le cas contraire, votre envoi
pourrait être rejeté car l'outil de maintenance de l'archive pourrait lire
le fichier changes
et constater que les fichiers ne
sont pas tous présents.
Les paquets dupload ou dput pourront vous faciliter le travail lors du téléchargement. Ces programmes bien pratiques aident à automatiser le processus d'envoi de paquets vers Debian.
Pour supprimer des paquets, veuillez lire le fichier ftp://ftp.upload.debian.org/pub/UploadQueue/README et le paquet Debian dcut.
Il peut être utile d'envoyer un paquet à un moment donné, mais vouloir que
ce paquet n'entre dans l'archive que quelques jours plus plus tard. Par
exemple, lors de la préparation d'une mise à jour
indépendante (« Non-Maintainer Upload
» ou NMU),
vous pourriez vouloir donner quelques jours au responsable pour réagir.
Les envois vers le répertoire différé sont gardés dans la file d'attente
différée. Une fois le temps d'attente indiqué terminé, le paquet est
déplacé dans le répertoire incoming
normal pour être
traité. Cela est réalisé par une mise à jour automatique en envoyant dans le
répertoire DELAYED/
(X
-dayX
compris entre 0 et 15) de
ftp.upload.debian.org
. Le contenu de 0-day
est envoyé plusieurs fois par jour vers
ftp.upload.debian.org
.
Avec dput, le paramètre --delayed
permet de placer le paquet dans
une des files d'attente.
DELAY
Do NOT upload a package to the security
upload queue (on *.security.upload.debian.org
) without
prior authorization from the security team. If the package does not exactly
meet the team's requirements, it will cause many problems and delays in
dealing with the unwanted upload. For details, please see Section 5.8.5, « Gestion des bogues de sécurité ».
Une file d'attente alternative en Europe est disponible sur ftp://ftp.eu.upload.debian.org/pub/UploadQueue/. Son fonctionnement est
similaire à ftp.upload.debian.org
, mais devrait être plus
rapide pour les responsables européens.
Les paquets peuvent également être envoyés à l’aide de ssh sur
ssh.upload.debian.org
; les fichiers doivent être placés dans
/srv/upload.debian.org/UploadQueue
. Cette file d'attente
ne permet pas les envois différés.
Les administrateurs de l'archive Debian sont responsables de l'installation
des mises à jour. La plupart des mises à jour sont gérées quotidiennement
par le logiciel de gestion de l'archive dak
process-upload. Les mises à jour de paquets sur la distribution
unstable
sont ainsi installées automatiquement. Dans les
autres cas et notamment dans le cas d'un nouveau paquet, celui-ci sera
installé manuellement. Il peut s'écouler un peu de temps entre l'envoi d'un
paquet vers un serveur et son installation effective. Veuillez être patient.
Dans tous les cas, vous recevrez un accusé de réception par courrier électronique indiquant que votre paquet a été installé et quels rapports de bogue ont été clos. Veuillez lire attentivement ce courrier et vérifier que tous les rapports de bogue que vous vouliez clore sont bien dans cette liste.
L'accusé de réception indique aussi la section dans laquelle le paquet a été installé. S'il ne s'agit pas de votre choix, vous recevrez un second courrier qui vous informera de cette différence (voir ci-dessous).
Notez que si vous envoyez en utilisant les files d'attente, le démon vous enverra également une notification par courrier électronique.
Also note that new uploads are announced on the IRC channel
#debian-devel-changes
. If your upload fails silently, it
could be that your package is improperly signed, in which case you can find
more explanations on
ssh.upload.debian.org:/srv/upload.debian.org/queued/run/log
.
Les champs Section
et Priority
du
fichier debian/control
ne précisent pas vraiment
l'endroit où le fichier sera placé dans l'archive, ni sa priorité. Afin de
conserver l'intégrité globale de l'archive, ce sont les administrateurs de
l'archive qui contrôlent ces champs. Les valeurs dans le fichier
debian/control
sont seulement indicatives.
Les administrateurs de l'archive indiquent les sections et priorités des
paquets dans le fichier override
. Si ce fichier
override
et le fichier
debian/control
du paquet diffèrent, vous en serez
informé par courrier électronique quand le paquet sera installé dans
l'archive. Vous pouvez corriger votre fichier
debian/control
avant votre prochain envoi ou alors vous
pouvez modifier le fichier override
.
Pour modifier la section dans laquelle un paquet est archivé, vous devez
d'abord vérifier que le fichier debian/control
est
correct. Ensuite, envoyez un rapport de bogue sur le pseudo-paquet
ftp.debian.org
demandant la
modification de la section ou de la priorité de votre paquet. Utilisez un
sujet comme override: PACKAGE1:section/priorité, [...], PACKAGEX:
section/priorité
, et exposez bien les raisons qui vous amènent à
demander ces changements dans le corps de texte.
Pour en savoir plus sur les fichiers override
,
reportez-vous à dpkg-scanpackages(1) et https://www.debian.org/Bugs/Developer#maintincorrect.
Notez que le champ Section
décrit à la fois la section et
la sous-section, comme décrit en Section 4.6.1, « Sections ». Si la
section est main
, elle devrait être omise. La liste des
sous-sections autorisées peut être trouvée en https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections.
Chaque développeur doit être capable de travailler avec le système de suivi des bogues (« bug tracking
system
» ou BTS) Debian. Il faut savoir comment remplir
des rapports de bogue correctement (voir Section 7.1, « Signalement de bogues »),
comment les mettre à jour, les réordonner, les traiter et les fermer.
Les fonctionnalités du système de suivi des bogues sont décrites dans la documentation du BTS pour les développeurs : fermeture de bogues, envoi de messages de suivi, assignation de niveaux de gravité et de marques, indication que les bogues ont été transmis aux développeurs amonts, etc.
Des opérations comme réassigner des bogues à d'autres paquets, réunir des rapports de bogues séparés traitant du même problème ou rouvrir des bogues quand ils ont été prématurément fermés, sont gérées en utilisant le serveur de contrôle par courrier. Toutes les commandes disponibles pour ce serveur sont décrites dans la documentation du serveur de contrôle du BTS.
Être un bon responsable implique de consulter régulièrement la page du
système de suivi des bogues (BTS) de vos
paquets. Le système de suivi des bogues contient tous les rapports de bogue
qui concernent vos paquets. Vous pouvez les vérifier en consultant cette
page :
https://bugs.debian.org/
.
votrecompte
@debian.org
Les responsables interagissent avec le système de suivi des bogues en
utilisant l'adresse électronique bugs.debian.org
. Vous
trouverez une documentation sur les commandes disponibles à l'adresse https://www.debian.org/Bugs/ ou, si vous avez installé le paquet doc-debian
, dans les fichiers locaux
/usr/share/doc/debian/bug-*
.
Certains trouvent utile de recevoir régulièrement une synthèse des rapports de bogue ouverts. Si vous voulez recevoir une synthèse hebdomadaire relevant tous les rapports de bogue ouverts pour vos paquets, vous pouvez configurer cron comme suit :
# Synthèse hebdomadaire des rapports de bogue qui me concernent
0 17 * * fri echo "index maint address
" | mail request@bugs.debian.org
Remplacez address
par votre adresse officielle de
responsable Debian.
Lorsque vous répondez à des rapports de bogue, assurez-vous que toutes vos
discussions concernant les bogues sont envoyées au rapporteur du bogue et au
bogue lui-même (<
par exemple). Si vous rédigez un nouveau courrier et si vous ne vous
souvenez plus de l'adresse du rapporteur de bogue, vous pouvez utiliser
l'adresse
123
@bugs.debian.org><
pour
contacter le rapporteur et enregistrer votre courrier
dans le journal du bogue (ce qui signifie que vous n'avez pas besoin
d'envoyer une copie du courrier à
123
-submitter@bugs.debian.org><
).
123
@bugs.debian.org>
Si vous recevez un rapport de bogue mentionnant « FTBFS », cela signifie une
erreur de construction à partir du paquet source (« Fails To Build
From Source
»). Les porteurs emploient fréquemment cet acronyme.
Une fois un bogue traité (c'est-à-dire qu'il est corrigé), marquez-le comme
done
(il sera fermé) en envoyant un message d'explication
à <
. Si vous
corrigez un bogue en changeant et en envoyant une nouvelle version du
paquet, vous pouvez fermer le bogue automatiquement comme décrit en Section 5.8.4, « Fermeture des rapports de bogue lors des mises à jour ».
123
-done@bugs.debian.org>
Vous ne devez jamais fermer un rapport de bogue en
envoyant la commande close
à l'adresse
<control@bugs.debian.org>
. Si vous le faites, le rapporteur n'aura aucune
information sur la clôture de son rapport.
En tant que responsable de paquet, vous trouverez fréquemment des bogues dans d'autres paquets et recevrez des rapports de bogue sur vos paquets qui sont en fait relatifs à d'autres paquets. Les fonctions intéressantes du système de suivi des bogues sont décrites dans la documentation du BTS pour les développeurs Debian. Les instructions du serveur de contrôle du BTS documentent les opérations techniques du BTS, telles que comment remplir, réassigner, regrouper et marquer des bogues. Cette section contient des lignes directrices pour gérer vos propres bogues, définies à partir de l'expérience collective des développeurs Debian.
Remplir des rapports de bogue pour des problèmes que vous trouvez dans d'autres paquets est l'une des « obligations civiques » du responsable, voir Section 7.1, « Signalement de bogues » pour les détails. Cependant, gérer les bogues de vos propres paquets est encore plus important.
Voici une liste des étapes que vous pouvez suivre pour traiter un rapport de bogue :
décider si le rapport correspond à un bogue réel ou non. Parfois, les utilisateurs utilisent simplement un programme d'une mauvaise façon car ils n'ont pas lu la documentation. Si c'est votre diagnostic, fermez simplement le bogue avec assez d'informations pour laisser l'utilisateur corriger son problème (donnez des indications vers la bonne documentation et ainsi de suite). Si le rapport de bogue revient régulièrement, vous devriez vous demander si la documentation est assez bonne ou si le programme ne devrait pas détecter une mauvaise utilisation pour donner un message d'erreur informatif. Il s'agit d'un problème qui peut être discuté avec l'auteur amont.
Si le rapporteur de bogue n'est pas d'accord avec votre décision de
fermeture du bogue, il peut le rouvrir jusqu'à ce que vous trouviez un
accord sur la façon de le gérer. Si vous n'en trouvez pas, vous pouvez
marquer le bogue wontfix
pour indiquer aux personnes que
le bogue existe, mais ne sera pas corrigé. Si cette situation n'est pas
acceptable, vous (ou le rapporteur) pouvez vouloir demander une décision par
le comité technique en réassignant le bogue à tech-ctte
(vous pouvez utiliser la commande
clone
du BTS si vous désirez garder le bogue comme
rapporté sur votre paquet). Avant de faire cela, veuillez lire la procédure recommandée ;
si le bogue est réel, mais causé par un autre paquet, réassignez simplement
le bogue à l'autre paquet. Si vous ne savez pas à quel paquet il doit être
réassigné, vous pouvez demander de l'aide sur IRC ou sur <debian-devel@lists.debian.org>
. Veuillez
informer le ou les responsables du paquet sur lequel est réassigné le bogue,
par exemple en envoyant une copie du message de réassignation à
<
,
en expliquant vos raisons. Attention, une simple réassignation n'envoie
pas de courrier aux mainteneurs du paquet auquel le
bogue est réassigné, de ce fait ils n'apprendraient l'existence du bogue
qu'en regardant la vue d'ensemble des bogues relatifs à leurs paquets.
nomdupaquet
@packages.debian.org>
Si le bogue affecte le fonctionnement de votre paquet, veuillez envisager de cloner le bogue avant de le réassigner au paquet qui provoque vraiment le comportement. Si vous procédez autrement, le bogue ne sera pas vu dans la liste des bogues sur votre paquet, au risque que d'autres utilisateurs signalent le même bogue de nouveau. Vous devriez marquer « votre » bogue bloqué par le clone réassigné afin de documenter la relation entre les deux bogues ;
parfois, vous devez également ajuster la gravité du bogue pour qu'elle
corresponde à la définition de gravité des bogues. C'est dû au fait que les
gens tendent à augmenter la gravité des bogues pour s'assurer que leurs
bogues seront corrigés rapidement. La gravité de certains bogues peut même
être rétrogradée en wishlist
(souhait) quand le
changement demandé est seulement superficiel ;
si le bogue est réel, mais que le problème a déjà été rapporté auparavant,
alors les deux rapports devraient être rassemblés en un seul à l'aide de la
commande merge
du BTS. De cette façon, quand un bogue
sera corrigé, tous les rapporteurs en seront informés (veuillez notez,
néanmoins, qu'un courrier envoyé au rapporteur d'un des bogues ne sera pas
automatiquement envoyé aux autres rapporteurs) ;
le rapporteur de bogue peut avoir oublié de fournir certaines
informations. Dans ce cas, vous devez lui demander les informations
nécessaires. Vous pouvez utiliser la marque moreinfo
(plus d'information) sur le bogue. De plus, si vous ne pouvez pas reproduire
le bogue, vous pouvez le marquer comme unreproducible
(non reproductible). Une personne qui arriverait à reproduire le bogue est
alors invitée à fournir plus d'informations sur la façon de le
reproduire. Après quelques mois, si cette information n'a été envoyée par
personne, le bogue peut être fermé ;
si le bogue est lié à l'empaquetage, vous devez simplement le corriger. Si
vous ne pouvez pas le corriger vous-même, marquez alors le bogue avec
help
(aide). Vous pouvez également demander de l'aide sur
<debian-devel@lists.debian.org>
ou <debian-qa@lists.debian.org>
. S'il s'agit d'un problème amont,
vous devez faire suivre le rapport à l'auteur amont. Faire suivre un bogue
n'est pas suffisant, vous devez vérifier à chaque version si le bogue a été
corrigé ou non. S'il a été corrigé, il vous suffit de le clôturer, sinon
vous devez le rappeler à l'auteur. Si vous avez les compétences nécessaires,
vous pouvez préparer un correctif pour le bogue et l'envoyer en même temps à
l'auteur. Assurez-vous d'envoyer le correctif au BTS et marquez le bogue
avec patch
(correctif) ;
si un bogue a été corrigé sur la copie locale ou sur le système de gestion
de versions, il peut être marqué pending
(en attente)
pour signaler qu'il est corrigé, et sera fermé à la prochaine mise à jour
(ajouter « closes:
» dans
changelog
). C'est d'autant plus utile si plusieurs
développeurs travaillent sur le même paquet ;
Once a corrected package is available in the archive, the bug should be closed indicating the version in which it was fixed. This can be done automatically; read Section 5.8.4, « Fermeture des rapports de bogue lors des mises à jour ».
Au fur et à mesure que les bogues et problèmes sont corrigés dans vos paquets, il est de votre responsabilité en tant que responsable du paquet de fermer les rapports de bogue associés. Cependant, vous ne devez pas les fermer avant que le paquet n'ait été accepté dans l'archive Debian. C'est pourquoi, vous pouvez et devriez clore les rapports dans le système de suivi des bogues une fois que vous avez reçu l'avis indiquant que votre nouveau paquet a été installé dans l'archive. Le bogue devrait être fermé avec la bonne version.
Cependant, il est possible de fermer automatiquement les bogues après
l'envoi — indiquez simplement les bogues corrigés dans le fichier
debian/changelog
en suivant une syntaxe précise, et le
logiciel de maintenance de l'archive s'occupera de le fermer pour vous. Par
exemple :
acme-cannon (3.1415) unstable; urgency=low * Frobbed with options (closes: Bug#98339) * Added safety to prevent operator dismemberment, closes: bug#98765, bug#98713, #98714. * Added man page. Closes: #98725.
D'un point de vue technique, l'expression rationnelle Perl suivante décrit
comment sont identifiées les fermetures de bogue dans les lignes de
changelog
:
/closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig
We prefer the closes: #
syntax, as it is the most concise entry and the easiest to integrate with
the text of the XXX
changelog
. Unless specified
differently by the -v
-switch to
dpkg-buildpackage, only the bugs closed in the most
recent changelog entry are closed (basically, exactly the bugs mentioned in
the changelog-part in the .changes
file are closed).
Historiquement, les envois identifiés comme mise à jour
indépendante (« non-maintainer upload
» ou NMU)
étaient marqués comme fixed
au lieu d'être fermés, mais
cette pratique a cessé avec l'ajout du suivi des versions. Le même
raisonnement s'applique à l'étiquette
fixed-in-experimental
.
Si vous entrez un numéro de bogue incorrect ou si vous oubliez un bogue dans
les entrées du fichier changelog
, n'hésitez pas à
annuler tout dommage que l'erreur a entraîné. Pour rouvrir un bogue fermé
par erreur, envoyez une commande reopen
à l'adresse de contrôle du système
de suivi des bogues, XXX
<control@bugs.debian.org>
. Pour fermer tous les bogues
restants qui ont été corrigés par votre envoi, envoyez le fichier
.changes
à
<
où
XXX
-done@bugs.debian.org>XXX
est le numéro du bogue et placez « Version:
YYY
» et une ligne vide comme deux premières
lignes du corps du courrier où YYY
est la
première version dans laquelle le bogue a été corrigé.
Rappelez-vous qu'il n'est pas obligatoire de fermer les bogues en utilisant
le changelog
tel que décrit ci-dessus. Si vous désirez
simplement fermer les bogues qui n'ont rien à voir avec l'un de vos envois,
faites-le simplement en envoyant une explication à
<
. Vous ne
devez jamais fermer des bogues dans une
entrée du journal de modification (XXX
-done@bugs.debian.org>changelog
) si les
changements dans cette version n'ont rien à voir avec le bogue.
Pour une information plus générale sur ce qu'il faut mettre dans les entrées
du journal de modification (changelog
), voir Section 6.3, « Meilleures pratiques pour debian/changelog
».
À cause de leur nature sensible, les bogues liés à la sécurité doivent être
soigneusement traités. L'équipe de sécurité de Debian est là pour coordonner
cette activité, pour faire le suivi des problèmes de sécurité en cours, pour
aider les responsables ayant des problèmes de sécurité ou pour les corriger
elle-même, pour envoyer les annonces de sécurité et pour maintenir
security.debian.org
.
Si vous prenez connaissance d'un bogue lié à un problème de sécurité sur un
paquet Debian, que vous soyez ou non le responsable, regroupez les
informations pertinentes sur le problème et contactez rapidement l'équipe de
sécurité par courriel à <team@security.debian.org>
. Si vous le désirez, vous
pouvez chiffrer votre courriel avec la clé de contact de l’équipe de
sécurité ; consultez https://www.debian.org/security/faq#contact pour plus de
détails. N'envoyez pas de paquet pour
stable
sans contacter l'équipe de sécurité. Les
informations utiles comprennent, par exemple :
si le bogue a déjà été rendu public on non ;
les versions du paquet affectées par le bogue. Vérifiez chaque version
présente dans les distributions maintenues par Debian ainsi que dans
testing
et unstable
;
la nature d'une solution si elle existe (les correctifs sont particulièrement utiles) ;
Any fixed packages that you have prepared yourself (send the resulting
debdiff or alternatively only the .diff.gz
and
.dsc
files and read Section 5.8.5.4, « Préparation de paquets pour les problèmes de sécurité » first)
toute assistance possible pour aider à tester (exploitation de faille, tests de régression, etc.) ;
toute information utile pour l'annonce de sécurité (voir Section 5.8.5.3, « Annonces de sécurité »).
En tant que responsable d'un paquet, il est de votre devoir de le maintenir, même dans la distribution stable. Vous êtes le mieux placé pour apprécier les correctifs et tester les paquets mis à jour, donc merci de vous référer aux sections suivantes sur la façon de préparer les paquets pour l'équipe en charge de la sécurité.
L'équipe en charge de la sécurité gère une base de donnée centralisée, le
gestionnaire de sécurité
Debian (« Debian Security Tracker
»). Il contient
tous les renseignements possibles à propos des problèmes de sécurité
connus : quels sont les paquets et versions affectés et non affectés, et par
conséquent si stable
, testing
et
unstable
sont vulnérables. Les informations encore
confidentielles ne sont pas ajoutées à la base de données.
Il est possible de rechercher un problème particulier, mais aussi un paquet. Cherchez parmi vos paquets afin de prendre connaissance de problèmes non encore résolus. Si vous le pouvez, veuillez fournir plus d'informations sur ces problèmes, ou aidez à les corriger dans vos paquets. Le mode d'emploi est disponible sur les pages web du gestionnaire.
À la différence de la plupart des autres activités de Debian, les problèmes de sécurité doivent parfois être tenus secrets un certain temps. Cela permet aux distributeurs de logiciels de coordonner leur divulgation afin de minimiser l'exposition de leurs utilisateurs. Cette décision dépend de la nature du problème, de l'existence d'une solution correspondante, et de sa publicité.
Il existe plusieurs façons pour un développeur de prendre connaissance d'un problème de sécurité :
il le remarque sur un forum public (liste de diffusion, site web, etc.) ;
quelqu'un soumet un rapport de bogue ;
quelqu'un l'informe en privé.
Dans les deux premiers cas, l'information est publique et il est important de régler le problème au plus vite. Dans le dernier cas, cependant, l'information n'est pas forcément publique. Il existe alors différentes possibilités pour traiter le problème :
si l'exposition est mineure, il n'y a parfois pas besoin de garder le secret sur le problème et une correction devrait être mise en œuvre et diffusée ;
si le problème est grave, il vaut mieux partager cette information avec d'autres distributeurs et de coordonner une publication. L'équipe de sécurité est en contact avec les différentes organisations et individus et peut s'en occuper.
Dans tous les cas, si la personne ayant indiqué le problème demande à ce que
l'information ne soit pas diffusée, cela devrait être respecté, avec
l'évidente exception d'informer l'équipe de sécurité pour préparer un
correctif de la version stable
de Debian. Quand vous
envoyez des informations confidentielles à l'équipe de sécurité,
assurez-vous de bien le préciser.
Si le secret est nécessaire, vous ne pourrez pas envoyer de correctif vers
unstable
(ou ailleurs, comme un système de gestion de
version public). Il ne suffit pas d'occulter les détails des modifications :
puisque le code lui même est public, il peut être (et sera) étudié.
Il existe deux raisons de diffuser l'information même si le secret est demandé : le problème est connu depuis un certain temps, ou le problème ou son exploitation est devenu public.
L'équipe de sécurité dispose d'une clé PGP pour permettre de chiffrer tout échange d'informations pour les problèmes sensibles. Voir la FAQ de l'équipe Debian sur la sécurité pour plus de détails.
Les annonces de sécurité ne sont émises que pour la distribution
actuellement stable
, mais pas pour
testing
ou unstable
. Une fois
diffusée, l'annonce est envoyée à la liste <debian-security-announce@lists.debian.org>
et mise en ligne sur la page d'informations de sécurité. Les
annonces de sécurité sont écrites et mises en ligne par les membres de
l'équipe en charge de la sécurité. Cependant, ils ne verront aucun
inconvénient à ce qu'un responsable leur apporte des informations ou écrive
une partie du texte. Les informations d'une annonce devraient comporter :
une description du problème et de sa portée, y compris :
le type du problème (usurpation de privilège, déni de service, etc.),
quels sont les privilèges obtenus et par quels utilisateurs (si c'est le cas),
comment il peut être exploité,
si le problème peut être exploité à distance ou localement,
comment le problème a été corrigé,
ces informations permettent aux utilisateurs d'estimer la menace pesant sur leurs systèmes ;
les numéros de version des paquets affectés ;
les numéros de version des paquets corrigés ;
une information sur la façon de récupérer les paquets mis à jour (habituellement l'archive de sécurité Debian) ;
des références à des annonces amont, des identifiants CVE et toute autre information utile pour recouper les références de la vulnérabilité.
Une façon d'aider l'équipe de sécurité dans sa tâche est de lui fournir des
paquets corrigés adéquats pour une annonce de sécurité de la version
stable
de Debian.
When an update is made to the stable release, care must be taken to avoid changing system behavior or introducing new bugs. In order to do this, make as few changes as possible to fix the bug. Users and administrators rely on the exact behavior of a release once it is made, so any change that is made might break someone's system. This is especially true of libraries: make sure you never change the API (Application Program Interface) or ABI (Application Binary Interface), no matter how small the change.
Cela signifie que passer à une version amont supérieure n'est pas une bonne
solution. À la place, les changements pertinents devraient être rétroportés
vers la version actuelle de la distribution stable
de
Debian. Habituellement, les développeurs amont veulent bien aider. Sinon,
l'équipe de sécurité Debian peut le faire.
Dans certains cas, il n'est pas possible de rétroporter un correctif de sécurité, par exemple, quand de grandes quantités de code source doivent être modifiées ou réécrites. Si cela se produit, il peut être nécessaire de passer à une nouvelle version amont. Cependant, cela n'est fait que dans des situations extrêmes et vous devez toujours coordonner cela avec l'équipe de sécurité auparavant.
Une autre règle importante découle de ce qui précède : testez toujours vos changements. Si une exploitation du problème existe, essayez-la et vérifiez qu'elle réussit sur le paquet non corrigé et échoue sur le paquet corrigé. Testez aussi les autres actions normales, car un correctif de sécurité peut parfois casser de manière subtile des fonctionnalités apparemment découplées.
N'ajoutez pas de modifications au paquet qui ne soient pas directement liées à la correction de la vulnérabilité. Celles-ci devraient alors être enlevées, ce qui ne représentera qu'une perte de temps. S'il y a d'autres bogues dans votre paquet que vous aimeriez corriger, faites un envoi vers proposed-updates de la façon habituelle, après l'envoi de l'alerte de sécurité. Le mécanisme de mise à jour de sécurité n'est pas un moyen d'introduire des changements dans votre paquet qui serait sinon rejeté de la distribution stable, veuillez donc ne pas essayer de le faire.
Examinez et testez autant que possible vos changements. Vérifiez les
différences avec la version précédente de manière répétée
(interdiff du paquet patchutils
et debdiff du
paquet devscripts
sont des outils
pratiques pour cela, voir Section A.2.2, « debdiff »).
Assurez-vous de garder les points suivants à l'esprit :
Target the right distribution in your
debian/changelog
:
codename
-security
(e.g. stretch-security
). Do not target
distribution
-proposed-updates
or stable
!
l'envoi devra être fait avec urgency=high ;
fournissez des entrées de changelog
descriptives et
complètes. D'autres personnes se baseront dessus pour déterminer si un bogue
particulier a été corrigé. Ajoutez la déclaration closes:
pour tout bogue Debian. Intégrez toujours
une référence externe, de préférence un identifiant
CVE, pour qu'elle puisse être recoupée. Néanmoins, si aucun
identifiant CVE n'a encore été assigné, ne l'attendez pas et continuez le
processus. L'identifiant pourra être référencé plus tard ;
Make sure the version number is proper.
It must be greater than the current package, but less than package versions
in later distributions. If in doubt, test it with dpkg
--compare-versions
. Be careful not to re-use a version number
that you have already used for a previous upload, or one that conflicts with
a binNMU. The convention is to append
+deb
X
u1
(where X
is the major release number), e.g.
1:2.4.3-4+deb9u1
, of course increasing 1
for any subsequent uploads.
à moins que l'archive source amont n'ait déjà été envoyée à
security.debian.org
(lors d'une précédente mise à jour de
sécurité), construisez le paquet en incluant l'archive source amont complète (dpkg-buildpackage
-sa
). Si l'archive source amont a déjà été envoyée à
security.debian.org
, vous pouvez préparer le paquet en
l'excluant (dpkg-buildpackage -sd
) ;
assurez-vous d'utiliser exactement le même
*.orig.tar.{gz,bz2,xz}
que celui utilisé
dans l'archive normale, sinon il ne sera pas possible de déplacer plus tard
le correctif de sécurité dans l'archive principale ;
compilez le paquet sur un système propre,
où tous les paquets appartiennent à la distribution pour laquelle vous
construisez le paquet. Si vous ne disposez pas d’un tel système, vous pouvez
utiliser l'une des machines de debian.org (voir Section 4.4, « Serveurs Debian ») ou mettre en place un chroot (voir Section A.4.3, « pbuilder
» et Section A.4.2, « debootstrap
»).
Do NOT upload a package to the security
upload queue (on *.security.upload.debian.org
) without
prior authorization from the security team. If the package does not exactly
meet the team's requirements, it will cause many problems and delays in
dealing with the unwanted upload.
Vous ne devez jamais envoyer votre
correction dans proposed-updates
sans vous coordonner
avec l'équipe de sécurité. Les paquets seront copiés de
security.debian.org
au répertoire
proposed-updates
automatiquement. Si un paquet avec le
même numéro de version ou un numéro plus grand est déjà installé dans
l'archive, la mise à jour de sécurité sera rejetée par le système
d'archive. Ainsi, la distribution stable
se retrouvera
plutôt sans la mise à jour de sécurité de ce paquet.
Once you have created and tested the new package and it has been approved by
the security team, it needs to be uploaded so that it can be installed in
the archives. For security uploads, the place to upload to is
ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue/
.
Une fois l'envoi vers la file d'attente de sécurité accepté, le paquet sera automatiquement recompilé pour toutes les architectures et stocké pour vérification par l'équipe de sécurité.
Uploads that are waiting for acceptance or verification are only accessible by the security team. This is necessary since there might be fixes for security problems that cannot be disclosed yet.
Si une personne de l'équipe de sécurité accepte un paquet, il sera installé
sur security.debian.org
et proposé pour le répertoire
distribution
-proposed-updates
adéquat sur ftp-master.debian.org
.
Certaines manipulations de l'archive ne sont pas possibles avec le processus de mise à jour automatisé. Elles sont effectuées manuellement par les responsables. Cette partie décrit la marche à suivre dans ces situations.
Il arrive parfois qu'un paquet change de section. Un paquet de la section
non-free
pourrait, par exemple, être distribué sous
licence GNU GPL dans une nouvelle version ; dans ce cas, le paquet devrait
être déplacé vers la section main
ou
contrib
.[3]
Pour changer la section d'un paquet, modifiez les informations de contrôle
pour placer le paquet dans la section voulue et envoyez-le à nouveau dans
l'archive (voir la Charte Debian
pour plus d'informations). Assurez-vous d'inclure le fichier
.orig.tar.{gz,bz2,xz}
dans l'envoi (même si vous
n'envoyez pas de nouvelle version amont) sinon il n'apparaîtra pas dans la
nouvelle section avec le reste du paquet. Si la nouvelle section est
valable, il sera déplacé automatiquement. Si ce n'est pas le cas, contactez
les responsables de l'archive (« ftpmasters
») pour
comprendre ce qui s'est passé.
Pour changer la sous-section d'un paquet (devel
ou
admin
par exemple), la procédure est légèrement
différente. Modifiez la sous-section dans le fichier de contrôle du paquet
et renvoyez-le. Il vous faudra ensuite demander la modification du fichier
override
comme décrit en Section 5.7, « Section, sous-section et priorité de paquet ».
If for some reason you want to completely remove a package (say, if it is an
old compatibility library which is no longer required), you need to file a
bug against ftp.debian.org
asking
that the package be removed; as with all bugs, this bug should normally have
normal severity. The bug title should be in the form RM:
, where
package
[architecture
list]
-- reason
package
is the package to be removed and
reason
is a short summary of the reason for the
removal request. [architecture list]
is optional
and only needed if the removal request only applies to some architectures,
not all. Note that the reportbug will create a title
conforming to these rules when you use it to report a bug against the
ftp.debian.org
pseudo-package.
If you want to remove a package you maintain, you should note this in the
bug title by prepending ROM
(Request Of Maintainer).
There are several other standard acronyms used in the reasoning for a
package removal; see https://ftp-master.debian.org/removals.html for a complete
list. That page also provides a convenient overview of pending removal
requests.
Note that removals can only be done for the unstable
,
experimental
and stable
distributions. Packages are not removed from testing
directly. Rather, they will be removed automatically after the package has
been removed from unstable
and no package in
testing
depends on it. (Removals from
testing
are possible though by filing a removal bug
report against the release.debian.org
pseudo-package. See Section 5.14.2.2, « Suppression de testing
».)
Il existe une exception pour laquelle il n'est pas nécessaire de faire une demande explicite de suppression : si un paquet (source ou binaire) ne se construit plus depuis le source, il sera supprimé de façon semi-automatique. Pour un paquet binaire, cela veut dire qu'il n'y a plus de paquet source produisant ce paquet binaire ; si le paquet binaire n'est simplement plus produit pour certaines architectures, une demande de suppression est toujours nécessaire. Pour un paquet source, cela veut dire que tous les paquets binaires auxquels il se réfère ont été récupérés par un autre paquet source.
Il faut détailler dans la demande de suppression les raisons de cette demande. Cela pour but d'éviter les suppressions indésirables et de garder une trace de la raison pour laquelle un paquet a été supprimé. Par exemple, vous pouvez fournir le nom du paquet qui remplace celui à supprimer.
Normalement, vous ne devriez demander la suppression d'un paquet que si vous
en êtes le responsable. Si vous voulez supprimer un autre paquet, vous devez
obtenir l'accord de son responsable. Dans le cas d'un paquet orphelin, qui
n'a donc pas de responsable, vous devriez discuter la demande de suppression
sur <debian-qa@lists.debian.org>
. S'il existe un consensus sur la suppression du
paquet, vous devriez changer le titre et réassigner le bogue
O:
au paquet wnpp
plutôt que d'en
ouvrir un autre.
Plus d'informations sur ce sujet et autres sujets connexes sont disponibles sur https://wiki.debian.org/ftpmaster_Removals et https://qa.debian.org/howto-remove.html.
Si vous ne savez pas bien si un paquet peut être supprimé, demandez l'avis
des autres développeurs sur la liste <debian-devel@lists.debian.org>
. Le programme
apt-cache du paquet apt
pourra aussi vous être utile. La commande
apt-cache showpkg
vous
indiquera, entre autres, les paquets qui dépendent de
paquet
paquet
. Parmi les programmes utiles, citons
apt-cache rdepends, apt-rdepends,
build-rdeps (du paquet devscripts
) et grep-dctrl. La
suppression de paquets orphelins est discutée sur <debian-qa@lists.debian.org>
.
Une fois le paquet supprimé, les bogues du paquet doivent être gérés. Soit
ils sont réassignés dans le cas où le code a évolué vers un autre paquet
(par exemple, libfoo12
a été supprimé parce que
libfoo13
le remplace), soit ils sont fermés si le
logiciel ne fait simplement plus partie de Debian. Lors de la fermeture des
bogues, pour éviter d'être marqués corrigés dans des versions du paquet
disponibles dans des distributions précédentes de Debian, ils devraient être
marqués corrigés dans la version
<dernière-version-existant-dans-Debian>+rm
.
Par le passé, il était possible de supprimer un paquet
d'incoming
. Cependant, ce n'est plus possible depuis la
mise en place du nouveau système. À la place, il faut envoyer une nouvelle
version du paquet avec un numéro de version plus élevé que celui à
remplacer. Les deux versions seront installées dans l'archive mais seule la
plus récente sera disponible dans unstable
car la
précédente sera immédiatement remplacée par la nouvelle. Toutefois, si vous
testez correctement vos paquets, vous ne devriez pas avoir besoin de les
remplacer trop souvent.
Quand les responsables amont d'un de vos paquet décident de renommer leur
logiciel (ou si vous vous trompez en nommant un paquet), vous devrez
intervenir en deux étapes pour changer son nom. D'abord, modifiez le fichier
debian/control
pour que le nouveau paquet remplace
(Replaces
), fournisse (Provides
) et
entre en conflit avec (Conflicts
) le paquet mal nommé
(reportez-vous à la Charte Debian
pour les détails). Vous ne devriez ajouter une relation
Provides
que si tous les paquets dépendants du paquet mal
nommé continuent de fonctionner après le changement de nom. Une fois le
paquet installé dans l'archive, faites un rapport de bogue concernant le
pseudopaquet ftp.debian.org
et
demandez la suppression du paquet mal nommé (voir Section 5.9.2, « Suppression de paquet »). N'oubliez pas de réassigner correctement les
bogues du paquet en même temps.
Vous pourriez aussi commettre une erreur en construisant le paquet et
voulant le remplacer. La seule façon de faire est d'incrémenter le numéro de
version et d'envoyer une nouvelle version. L'ancienne version expirera de la
façon habituelle. Notez que cela s'applique à chaque partie de votre paquet,
y compris les sources : pour remplacer l'archive source amont de votre
paquet, envoyez-la avec un numéro de version différent. Une possibilité
simple est de remplacer foo_1.00.orig.tar.gz
par
foo_1.00+0.orig.tar.gz
ou
foo_1.00.orig.tar.bz2
. Cette restriction permet à
chaque fichier de l'archive d'avoir un nom unique, ce qui aide à garantir la
cohérence dans le réseau des miroirs.
Si vous ne pouvez plus maintenir un paquet, il faut en informer les autres
et faire le nécessaire pour le marquer orphaned
(orphelin). Vous devriez remplacer votre nom par Debian QA Group
<packages@qa.debian.org>
dans le champ Maintainer
du
paquet et faire un rapport de bogue sur le pseudopaquet wnpp
. Le titre de votre rapport de bogue devrait
être « O:
» pour indiquer que
le paquet est orphelin (paquet
--
description courte
O
signifie
« Orphaned
» : orphelin). La gravité du bogue sera
normal
; si le paquet a une priorité standard ou
supérieure, elle devrait être important
. Si vous le jugez
nécessaire, envoyez une copie à <debian-devel@lists.debian.org>
en mettant cette
adresse dans le champ X-Debbugs-CC
de l'en-tête du
message. N'utilisez pas le champ CC
sinon le sujet du
message ne contiendra pas le numéro du bogue.
Si vous avez simplement l'intention de donner le paquet, mais que vous
pouvez conserver sa maintenance pour le moment, vous devriez plutôt
soumettre un rapport de bogue sur wnpp
intitulé RFA:
. package
-- description
courte
RFA
signifie
« Request For Adoption
» (demande d'adoption).
Vous pouvez trouver plus d'informations sur les pages web WNPP
(« Work-Needing and Prospective Packages
» : paquets en
souffrance et paquets souhaités).
Une liste des paquets en attente de nouveau responsable est disponible dans
la liste des paquets en souffrance et paquets
souhaités (WNPP
). Afin de prendre en charge un
paquet de cette liste, reportez-vous à la page mentionnée précédemment pour
plus d'informations et les procédures à suivre.
It is not OK to simply take over a package without assent of the current maintainer — that would be package hijacking. You can, of course, contact the current maintainer and ask them for permission to take over the package.
However, when a package has been neglected by the maintainer, you might be able to take over package maintainership by following the package salvaging process as described in Section 5.12, « Package Salvaging ». If you have reason to believe a maintainer is no longer active at all, see Section 7.4, « Gestion des responsables non joignables ».
Complaints about maintainers should be brought up on the developers' mailing list. If the discussion doesn't end with a positive conclusion, and the issue is of a technical nature, consider bringing it to the attention of the technical committee (see the technical committee web page for more information).
If you take over an old package, you probably want to be listed as the
package's official maintainer in the bug system. This will happen
automatically once you upload a new version with an updated
Maintainer
field, although it can take a few hours after
the upload is done. If you do not expect to upload a new version for a
while, you can use Section 4.10, « The Debian Package Tracker » to get the bug reports.
However, make sure that the old maintainer has no problem with the fact that
they will continue to receive the bugs during that time.
Les paquets sont souvent supprimés à cause de bogues critiques pour la publication, de mainteneurs absents, de trop peu d'utilisateurs ou d'une médiocre qualité générale. Alors que le processus de réintroduction de paquet est similaire au processus d'empaquetage initial, certains pièges peuvent être évités en commençant par un peu de recherche historique.
Vous devriez d'abord vérifier la raison pour laquelle le paquet a été supprimé. Ces renseignements sont disponibles dans le paragraphe suppression (« removal ») de la section de nouvelles du PTS pour le paquet ou en consultant le journal des suppressions. Le bogue de suppression indiquera la raison pour laquelle le paquet a été supprimé et donnera quelques indications sur les points à travailler avant de réintroduire le paquet. Cela pourrait indiquer que la meilleure solution est d'utiliser un autre programme au lieu de réintroduire le paquet.
Contacter les précédents responsables peut être utile pour savoir s'ils ont commencé à réintroduire le paquet et s'ils sont intéressés à comaintenir le paquet ou parrainer le paquet si nécessaire.
Toutes les étapes nécessaires à l'introduction d'un nouveau paquet (Section 5.1, « Nouveaux paquets ») devraient être suivies.
You should base your work on the latest packaging available that is
suitable. That might be the latest version from
unstable
, which will still be present in the snapshot archive.
Le système de gestion de versions utilisé par les précédents mainteneurs
pourrait contenir des modifications utiles, y jeter un œil pourrait donc
être une bonne idée. Vérifiez si le fichier control
du
précédent paquet contient des en-têtes pointant vers le système de gestion
de versions du paquet et s'il existe encore.
Les suppressions de paquet d'unstable
(pas de
testing
, stable
ou
oldstable
) déclenchent la fermeture de tous les bogues
relatifs au paquet. Vous devriez passer en revue tous les bogues fermés (y
compris les bogues archivés) puis extraire et rouvrir tous ceux qui ont été
fermés avec une version se finissant par +rm
, et toujours
d'actualité. Tous ceux qui ne s'appliquent plus devraient être marqués comme
corrigés dans la version adéquate si elle est connue.
Debian gère un nombre croissant d'architectures. Même si vous n'êtes pas un porteur et que vous utilisez une seule architecture, il est de votre responsabilité de développeur d'être attentif aux questions de portabilité. C'est pourquoi il est important de lire ce chapitre même si vous n'êtes pas un porteur.
Porting is the act of building Debian packages for architectures that are
different from the original architecture of the package maintainer's binary
package. It is a unique and essential activity. In fact, porters do most
of the actual compiling of Debian packages. For instance, when a maintainer
uploads a (portable) source package with binaries for the
i386
architecture, it will be built for each of the other
architectures, amounting to 10 more builds.
Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans modification. Malheureusement, c'est rarement le cas. Cette section contient une liste d'erreurs régulièrement commises par les responsables Debian — problèmes courants qui bloquent souvent les porteurs et compliquent inutilement leur travail.
The first and most important thing is to respond quickly to bugs or issues raised by porters. Please treat porters with courtesy, as if they were in fact co-maintainers of your package (which, in a way, they are). Please be tolerant of succinct or even unclear bug reports; do your best to hunt down whatever the problem is.
Les problèmes les plus couramment rencontrés par les porteurs sont causés par des erreurs d'empaquetage dans le paquet source. Voici un pense-bête pour les points auxquels vous devez être attentif :
Make sure that your Build-Depends
and
Build-Depends-Indep
settings in
debian/control
are set properly. The best way to
validate this is to use the debootstrap
package to create an
unstable
chroot environment (see Section A.4.2, « debootstrap
»). Within that chrooted environment, install the
build-essential
package and any
package dependencies mentioned in Build-Depends
and/or
Build-Depends-Indep
. Finally, try building your package
within that chrooted environment. These steps can be automated by the use
of the pbuilder program, which is provided by the package
of the same name (see Section A.4.3, « pbuilder
»).
En cas de difficultés pour configurer un environnement
chrooté
, dpkg-depcheck pourra
peut-être vous aider (voir Section A.6.6, « dpkg-depcheck »).
Consultez la Charte Debian pour en savoir plus sur les dépendances de fabrication ;
ne choisissez pas d'autres valeurs que all
ou
any
pour le champ architecture sans avoir de bonnes
raisons. Trop souvent, les développeurs ne respectent pas les instructions
de la Charte Debian. Choisir la
valeur i386
ou amd64
est généralement
incorrect ;
vérifiez que le paquet source est correct. Faites dpkg-source -x
pour vous assurer que le
paquet se décompresse correctement. En utilisant le résultat de ce test,
construisez votre paquet binaire à l'aide de la commande
dpkg-buildpackage ;
paquet
.dsc
vérifiez que les fichiers debian/files
ou
debian/substvars
ne sont pas dans votre paquet
source. Ils doivent être effacés par la cible clean
de
debian/rules
;
Make sure you don't rely on locally installed or hacked configurations or
programs. For instance, you should never be calling programs in
/usr/local/bin
or the like. Try not to rely on
programs being set up in a special way. Try building your package on
another machine, even if it's the same architecture.
ne vous appuyez pas sur une installation préexistante du paquet (un sous-cas
de la remarque précédente). Il existe, bien sûr, des exceptions à cette
règle, mais soyez conscient que chaque cas comme celui-ci demande une mise
en place (« bootstrapping
») manuelle et ne peut être
automatisé par les services d'empaquetage ;
si possible, ne dépendez pas d'une version particulière d'un compilateur. Si vous ne pouvez pas faire autrement, assurez-vous que les dépendances de fabrication reflètent cette restriction, bien que vous cherchiez sûrement les problèmes, puisque certaines architectures s’uniformisent pour différents compilateurs.
vérifiez que le fichier debian/rules
distingue les
cibles binary-arch
et binary-indep
comme l'exige la Charte Debian. Vérifiez que ces cibles sont indépendantes
l'une de l'autre, c'est-à-dire, qu'il n'est pas nécessaire d'invoquer l'une
de ces cibles avant d'invoquer l'autre. Pour vérifier cela, essayez
d'exécuter dpkg-buildpackage -B.
Si le paquet se construit tel quel sur l'architecture visée, vous avez de la chance et votre travail est facile. Cette section s'applique dans ce cas ; elle décrit comment construire et installer correctement le paquet binaire dans l'archive Debian. Si vous devez modifier le paquet pour le rendre compilable sur la nouvelle architecture, il faudra faire une NMU sources, consultez plutôt Section 5.11.1, « NMU : quand et comment ».
Pour un envoi de portage, ne faites pas de changement dans les sources. Vous
n'avez pas besoin de modifier les fichiers du paquet source, y compris le
fichier debian/changelog
.
La manière d'invoquer dpkg-buildpackage est la suivante :
dpkg-buildpackage -B
-m
. Bien sûr, remplacez
adresse-porteur
adresse-porteur
par votre adresse
électronique. Cette commande construira les parties du paquet qui dépendent
de l'architecture, en utilisant la cible binary-arch
de
debian/rules
.
Si vous travaillez sur une machine Debian pour vos efforts de portage et que
vous devez signer l'envoi localement pour être accepté dans l'archive, vous
pouvez exécuter debsign sur le fichier
.changes
pour qu'il soit signé convenablement, ou
utiliser le mode de signature à distance de dpkg-sig.
Parfois, l'envoi du porteur initial pose problème car l'environnement dans lequel le paquet a été construit n'était pas bon (bibliothèques périmées ou obsolètes, mauvais compilateur, etc.). Il se peut que vous ayez à le recompiler dans un environnement mis à jour. Cependant, dans ce cas, vous devez changer le numéro de version pour que les mauvais anciens paquets soient remplacés dans l'archive Debian (dak refuse d'installer un nouveau paquet s'il n'a pas un numéro de version supérieur à celui actuellement disponible).
Vous devez vous assurer que votre binNMU ne rend pas le paquet non
installable. Cela peut arriver si un paquet source génère des paquets
dépendants et indépendants de l'architecture qui ont des interdépendances
créées par l’utilisation de la substitution de variable de dpkg
$(Source-Version)
.
Malgré la modification nécessaire du journal de modification
(changelog
), ce type de mise à jour est appelé binNMU
— il n'est pas nécessaire de reconsidérer le statut des paquets binaires des
autres architectures pour les marquer périmés ou à recompiler.
Ces recompilations nécessitent des numéros de version « magiques » pour que le système de maintenance de l'archive comprenne que, bien qu'il y ait une nouvelle version, il n'y a pas eu de modification des sources. Si vous ne faites pas cela correctement, les administrateurs de l'archive rejetteront votre mise à jour (car il n'y aura pas de code source associé).
Le « numéro magique » d'une NMU pour une recompilation particulière est
obtenu en utilisant un suffixe ajouté au numéro de version du paquet, de la
forme b
. Par exemple, si
la dernière version recompilée était la version numéro
2.9-3
, la
binNMU aura pour version 2.9-3+b1
. Si la dernière version
était 3.4+b1
(c'est-à-dire un paquet natif avec une
précédente NMU par recompilation), la binNMU aura le numéro de version
3.4+b2
.[4]
De manière similaire aux envois du porteur initial, la façon correcte
d'invoquer dpkg-buildpackage est
dpkg-buildpackage -B
pour ne construire que les parties
dépendant de l'architecture du paquet.
Les porteurs faisant des NMU source suivent normalement les instructions de
Section 5.11, « Mises à jour indépendantes (NMU
) », tout comme les non-porteurs. Les délais d'attente
sont cependant réduits car les porteurs doivent manipuler un grand nombre de
paquets. À nouveau, la situation diffère selon la distribution visée. Elle
varie également si l'architecture est candidate pour la prochaine version
stable ; les responsables de publication décident et annoncent quelles sont
les architectures candidates.
Si vous êtes porteur et faites une NMU pour unstable
, les
instructions précédentes sont applicables à deux différences près. Tout
d'abord, le temps d'attente raisonnable — délai entre le moment où vous
envoyez un rapport au BTS et le moment où vous pouvez faire une NMU — est de
sept jours. Ce délai peut être réduit si le problème est crucial et met
l'effort de portage en difficulté : c'est à la discrétion de l'équipe de
portage. (Souvenez-vous, il ne s'agit pas d'un règlement, mais de
recommandations communément acceptées). Pour les envois de
stable
ou testing
, veuillez d'abord
vous coordonner avec l'équipe de publication concernée.
Deuxième différence, les porteurs faisant des NMU source doivent choisir une
gravité serious
(sérieuse) ou supérieure quand ils
envoient leur rapport au BTS. Cela assure qu'un paquet source unique permet
de produire un paquet binaire pour chaque architecture maintenue au moment
de la sortie de la distribution. Il est très important d'avoir un paquet
source et un paquet binaire pour toutes les architectures pour être conforme
à plusieurs licences.
Les porteurs doivent éviter les correctifs qui contournent les bogues des
actuels versions de l'environnement de compilation, du noyau ou de la
libc
. Parfois, ces contournements ne peuvent être
améliorés. Si vous devez faire quelque chose de ce genre, marquez proprement
vos modifications avec des #ifdef
et documentez votre
contournement pour pouvoir le retirer une fois le problème externe disparu.
Les porteurs peuvent aussi avoir un dépôt non officiel pour publier le résultat de leur travail pendant le délai d'attente. Ainsi, d'autres personnes peuvent bénéficier du travail du porteur même pendant ce délai. Bien sûr, ces dépôts n'ont rien d'officiel, donc soyez sur vos gardes si vous les utilisez.
Une infrastructure et plusieurs outils sont disponibles pour faciliter l'automatisation du portage des paquets. Cette section contient un bref aperçu de cette automatisation et de ces outils ; veuillez vous reporter à la documentation des paquets ou les références pour des informations complètes.
Les pages web contenant l'état de chaque portage peuvent être trouvées à https://www.debian.org/ports/.
Chaque portage de Debian possède sa propre liste de diffusion. La liste des listes de diffusion de portage peut être trouvée à https://lists.debian.org/ports.html. Ces listes sont utilisées pour coordonner les porteurs et pour mettre en relation les utilisateurs d'un portage donné avec les porteurs.
Les descriptions de plusieurs outils de portage peuvent être trouvées en Section A.7, « Outils de portage ».
The wanna-build
system is used as a
distributed, client-server build distribution system. It is usually used in
conjunction with build daemons running the buildd
program. Build daemons
are ``slave'' hosts, which contact the central wanna-build
system to receive a list of packages
that need to be built.
wanna-build
is not yet available as
a package; however, all Debian porting efforts are using it for automated
package building. The tool used to do the actual package builds,
sbuild
, is available as a package;
see its description in Section A.4.4, « sbuild
». Please note that the
packaged version is not the same as the one used on build daemons, but it is
close enough to reproduce problems.
Most of the data produced by wanna-build
that is generally useful to porters
is available on the web at https://buildd.debian.org/. This data
includes nightly updated statistics, queueing information and logs for build
attempts.
Ce système est une fierté de Debian car il a de nombreux usages
potentiels. Il peut être utilisé par des groupes de développeurs
indépendants pour créer différentes variantes de Debian d'intérêt général ou
non (par exemple, une variante de Debian compilée avec des vérifications de
limites (« bounds checking
») de
gcc). Ce système permettra aussi de recompiler rapidement
toute une distribution.
L'équipe de wanna-build
, en charge
des empaqueteurs (« buildd
»), peut être contactée à
l'adresse électronique
debian-wb-team@lists.debian.org
. Pour savoir qui (équipe
de wanna-build
, équipe de
publication) et comment (courrier électronique, BTS) contacter, se reporter
à https://lists.debian.org/debian-project/2009/03/msg00096.html.
Lors d'une demande de mise à jour indépendante binaire
(binNMU
) ou de « rendu »
(« give-back
» : nouvel essai suite à une compilation
échouée), veuillez utiliser le format décrit en https://release.debian.org/wanna-build.txt.
Certains paquets ont encore des problèmes pour être construits ou pour
fonctionner sur certaines architectures prises en charge par Debian, et ne
peuvent pas du tout être portés, ou pas dans un délai raisonnable. Par
exemple, un paquet spécifique à SVGA (disponible uniquement sur
i386
et amd64
), ou qui utilise des
fonctionnalités spécifiques au matériel non gérées sur toutes les
architectures.
Pour éviter que des paquets cassés soient envoyés dans l'archive et qu'ils
fassent perdre le temps des empaqueteurs (« buildd
»),
vous devez faire plusieurs choses :
tout d'abord, assurez-vous que votre paquet échoue à la compilation sur les architectures qu'il ne gère pas. Il y a plusieurs façons de faire cela. Le meilleur moyen est d'avoir une petite suite de tests pendant la construction qui vérifiera la fonctionnalité et échouera si cela ne fonctionne pas. C'est de toute façon une bonne idée et empêchera (certains) des envois cassés pour toutes les architectures, cela permettra également au paquet d'être construit dès que la fonctionnalité nécessaire sera disponible.
De plus, si vous croyez que la liste des architectures gérées est plutôt
constante, vous devriez changer any
en une liste des
architectures gérées dans le fichier debian/control
.
Ainsi, la construction échouera également et l'indiquera à un lecteur humain
sans vraiment essayer ;
pour empêcher les compilateurs automatiques de tenter sans raison de
construire votre paquet, il doit être inclus dans
Packages-arch-specific
, une liste utilisée par le
script wanna-build. La version actuelle est disponible en
https://anonscm.debian.org/cgit/mirror/packages-arch-specific.git/tree/Packages-arch-specific ; veuillez consulter le début du fichier
pour savoir qui contacter pour le modifier.
Please note that it is insufficient to only add your package to
Packages-arch-specific
without making it fail to build
on unsupported architectures: A porter or any other person trying to build
your package might accidentally upload it without noticing it doesn't work.
If in the past some binary packages were uploaded on unsupported
architectures, request their removal by filing a bug against ftp.debian.org
.
By default packages from the non-free
section are not
built by the autobuilder network (mostly because the license of the packages
could disapprove). To enable a package to be built, you need to perform the
following steps:
vérifier s'il est légalement permis et techniquement possible de construire automatiquement le paquet ;
ajouter XS-Autobuild: yes
dans la partie en-tête de
debian/control
;
envoyer un courrier à <nonfree@release.debian.org>
et expliquer pourquoi le
paquet peut légalement et automatiquement être construit.
Chaque paquet est géré par un ou plusieurs responsables. Normalement, ce
sont eux qui travaillent sur les paquets et s'occupent de les mettre à
jour. Dans certains cas, il est utile que d'autres développeurs puissent
aussi envoyer une nouvelle version, par exemple pour résoudre un bogue dans
un paquet dont ils ne sont pas responsables, lorsque le responsable a besoin
d'aide pour réagir aux problèmes. De tels envois sont appelés
mises à jour indépendantes (« Non-Maintainer
Uploads
» ou NMU
).
Avant de procéder à une NMU, veuillez prendre en considération les questions suivantes.
Avez-vous adapté le NMU de façon à aider le responsable ? Puisqu’il pourrait exister un désaccord sur le fait que le responsable ait vraiment besoin d’aide ou pas, la file d’attente DELAYED est là pour donner au responsable le temps de réagir et permet, comme effet de bord, de permettre des révisions indépendantes du diff de la NMU.
Est-ce que votre NMU corrige réellement le bogue ? (« bogue » signifie
n’importe quelle sorte de bogue, p. ex. un bogue wishlist
(souhait) pour empaqueter une nouvelle version amont, mais l’impact sur le
responsable devra être minimisé avec soin). Corriger des problèmes
superficiels ou changer la façon d’empaqueter (p. ex. utiliser cdbs au lieu
de dh) dans les NMU est déconseillé.
Avez-vous laissé suffisamment de temps au responsable ? Quand le bogue a-t-il été reporté au BTS ? Être occupé pendant une semaine ou deux n'est pas exceptionnel. Le bogue est-il si grave qu'il doive être corrigé immédiatement, ou cela peut-il attendre encore quelques jours ?
Quelle confiance avez-vous dans vos modifications ? Souvenez-vous du serment d'Hippocrate : « je m'abstiendrai de tout mal ». Il est préférable de laisser un paquet avec un bogue ouvert grave plutôt qu'appliquer un correctif non fonctionnel ou un correctif qui cache le bogue sans le résoudre. Si vous n'êtes pas absolument sûr de vous, il pourrait être judicieux de chercher des conseils autour de vous. Rappelez-vous que si quelque chose est cassé par votre NMU, de nombreuses personnes seront mécontentes.
Have you clearly expressed your intention to NMU, at least in the BTS? If that didn't generate any feedback, it might also be a good idea to try to contact the maintainer by other means (email to the maintainer addresses or private email, IRC).
Si le responsable est habituellement actif et réactif, avez-vous tenté de le contacter ? En général il est préférable que le responsable prenne en charge lui-même un problème et qu'il lui soit offert une chance d'examiner et corriger votre correctif, car il est censé être mieux placé pour découvrir d'éventuels problèmes que vous pourriez rater. C'est souvent un gain de temps pour tout le monde si le responsable a la possibilité d'envoyer lui-même une correction.
Lors d'une NMU, vous devez d'abord vous assurer que votre intention est sans
ambiguïté. Ensuite, vous devez envoyer un correctif contenant les
différences entre le paquet actuel et votre proposition de NMU au BTS. Le
script nmudiff du paquet devscripts
pourrait être utile.
While preparing the patch, you had better be aware of any package-specific
practices that the maintainer might be using. Taking them into account
reduces the burden of integrating your changes into the normal package
workflow and thus increases the chances that integration will happen. A good
place to look for possible package-specific practices is debian/README.source
.
À moins d'avoir une excellente raison de ne pas le faire, vous devez laisser
du temps au responsable pour réagir (par exemple en envoyant le paquet dans
la file DELAYED
). Voici quelques valeurs recommandées
pour les délais :
envoi corrigeant seulement un bogue critique pour la publication ouvert il y a plus de sept jours, sans action du responsable sur le bogue pendant sept jours, et sans indication qu'un correctif est en cours : zéro jour ;
envoi corrigeant seulement un bogue critique pour la publication ouvert il y a plus de sept jours : deux jours ;
envoi corrigeant seulement un bogue critique pour la publication et important : cinq jours ;
autres NMU : dix jours.
Ces délais sont simplement donnés à titre indicatifs. Dans certains cas,
comme des envois corrigeant des problèmes de sécurité, ou corrigeant des
bogues insignifiants qui bloquent une transition, il est préférable que le
paquet atteigne unstable
au plus tôt.
Parfois, les responsables de publication peuvent décider d'accepter des
délais plus courts pour les NMU corrigeant un sous-ensemble de bogues (par
exemple les bogues critiques pour la publication ouverts il y a plus de sept
jours). Certains responsables s'inscrivent d'eux-mêmes à la liste permissive de NMU (« Low
Threshold NMU list
»), et acceptent que les NMU soient
effectuées sans délai. Mais même dans ce cas, il est toujours préférable de
laisser quelques jours au responsable pour réagir avant votre envoi,
d'autant plus si le correctif n'était pas disponible auparavant dans le BTS,
ou si vous savez que le responsable est habituellement actif.
Après une NMU, vous êtes responsable d'éventuels problèmes introduits. Vous devez garder un œil sur le paquet (s'abonner au paquet dans le PTS est un bon moyen).
Il ne s'agit pas d'un permis pour faire des NMU irréfléchies. Si vous procédez à une NMU alors que le responsable est clairement actif et aurait pris en considération un correctif de façon opportune, ou si vous passez outre les recommandations de ce document, votre envoi risque d'être une cause de conflit avec le responsable. Vous devriez toujours être prêt à défendre le bien-fondé de toute NMU effectuée.
Just like any other (source) upload, NMUs must add an entry to
debian/changelog
, telling what has changed with this
upload. The first line of this entry must explicitly mention that this
upload is an NMU, e.g.:
* Non-maintainer upload.
La façon de numéroter les versions lors d'une NMU est différente s'il s'agit d'un paquet natif ou non.
Si le paquet est natif (sans partie révision Debian dans le numéro de
version du paquet), la version doit être celle du dernier envoi du
responsable, suivi de +nmu
,
où X
X
est un compteur commençant à
1
. Si le dernier envoi était également une NMU, le
compteur devrait être augmenté. Par exemple, si la version actuelle est
1.5
, alors une NMU devrait prendre la version
1.5+nmu1
.
Si le paquet n'est pas natif, vous devriez ajouter un numéro de version
mineure à la partie révision Debian du numéro de version (la partie après le
dernier tiret). Ce numéro supplémentaire devrait commencer à
1
. Par exemple si la version actuelle est
1.5-2
, alors une NMU devrait prendre la version
1.5-2.1
. Si une nouvelle version amont est empaquetée
lors de la NMU, la révision Debian est configurée à 0
,
par exemple 1.6-0.1
.
Dans les deux cas, si le dernier envoi était également une NMU, le compteur
devrait être augmenté. Par exemple, si la version actuelle est
1.5+nmu3
(un paquet natif déjà mis à jour
indépendamment), la NMU devrait prendre la version
1.5+nmu4
.
Une numérotation de version spécifique est nécessaire pour éviter de
perturber le travail du responsable, car l'utilisation d'un entier dans la
révision Debian risque d'entrer en conflit avec un envoi déjà en préparation
lors de la NMU, ou même déjà dans la file d'attente de nouveaux paquets
(NEW
), Cela présente également l'avantage d'indiquer
clairement que le paquet dans l'archive n'a pas été préparé par le
responsable officiel.
If you upload a package to testing or stable, you sometimes need to "fork"
the version number tree. This is the case for security uploads, for
example. For this, a version of the form
+deb
should be used, where X
uY
X
is the major release
number, and Y
is a counter starting at
1
. For example, while stretch (Debian
9) is stable, a security NMU to stable for a package at
version 1.5-3
would have version
1.5-3+deb9u1
, whereas a security upload to
buster would get version
1.5-3+deb10u1
.
Attendre une réponse après avoir demandé la permission de procéder à une NMU
est inefficace, car cela coûte au demandeur un changement de contexte
(« context switch
») pour revenir sur le problème. La
file d'attente DELAYED/
(voir Section 5.6.2, « Envois différés ») permet au développeur préparant une NMU
d'accomplir toutes les tâches nécessaire en même temps. Par exemple, plutôt
que dire au responsable que vous allez envoyer le nouveau paquet dans sept
jours, vous devriez envoyer le paquet vers DELAYED/7
et
dire au responsable qu'il a sept jours pour réagir. Pendant ce temps, le
responsable peut vous demander de retarder un peu plus votre envoi, ou
l'annuler.
La file d'attente DELAYED
ne devrait pas être utilisée
pour augmenter la pression sur le responsable. Notamment, il est important
d'être disponible pour annuler ou retarder l'envoi avant la fin du délai car
le responsable ne peut pas le faire lui-même.
Si vous procédez à une NMU vers DELAYED
et que le
responsable envoie son paquet avant la fin du délai, votre envoi sera rejeté
car une nouvelle version sera alors disponible dans l'archive. Dans l'idéal,
le responsable se chargera d'intégrer votre proposition (ou du moins une
solution pour le problème en question) dans son envoi.
Quand quelqu'un réalise une NMU sur votre paquet, c'est pour vous aider à le garder en bon état. Cela permet aux utilisateurs d'obtenir un paquet corrigé au plus vite. Vous pouvez envisager de proposer à l'auteur de la NMU de devenir co-responsable du paquet. Recevoir une NMU sur un paquet n'est pas une mauvaise chose : cela signifie simplement que le paquet est suffisamment intéressant pour que d'autres personnes veuillent travailler dessus.
Pour prendre en compte une NMU, intégrez ses modifications et l'entrée de
journal de modification (changelog
) lors de votre envoi
suivant. Si vous ne prenez pas en compte la NMU en conservant l'entrée de
changelog
correspondante, le bogue restera fermé dans
le BTS mais sera listé comme affectant votre version du paquet.
Le nom complet pour une NMU est mise à jour indépendante source
(« source NMU
»). Il en existe aussi d'un
autre type, appelé mise à jour indépendante binaire
(« binary-only NMU
» ou
« binNMU
»). Une binNMU est aussi un paquet
envoyé par quelqu'un d'autre que le responsable du paquet. Cependant, seul
le paquet binaire est mis à jour.
Lorsqu'une bibliothèque (ou toute autre dépendance) est mise à jour, les paquets l'utilisant risquent de devoir être reconstruits. Puisque le code source n'a pas besoin d'être modifié, le même paquet source est utilisé.
Les binNMU sont généralement déclenchées sur les empaqueteurs
(« buildd
») par wanna-build
. Une entrée est ajoutée à
debian/changelog
expliquant pourquoi un envoi était
requis et le numéro de version est augmenté tel que décrit en Section 5.10.2.1, « Recompilation ou mise à jour indépendante binaire
(binNMU
) ». Cette entrée ne devrait pas être gardée lors de
l'envoi suivant.
Les empaqueteurs (« buildd
») envoient les paquets de
leur architecture comme des mises à jour binaires. Au sens strict, ce sont
des binNMU. Cependant, elles ne sont généralement pas appelées NMU, et
aucune entrée n'est ajoutée à debian/changelog
.
NMUs are uploads of packages by somebody other than their assigned maintainer. There is another type of upload where the uploaded package is not yours: QA uploads. QA uploads are uploads of orphaned packages.
Les envois de QA
ressemblent beaucoup à des envois
normaux de responsable : ils peuvent corriger quelque chose, même un
problème mineur ; la numérotation de version est normale, et il n'est pas
nécessaire d'utiliser d'envoi retardé. La différence est que vous ne faites
pas partie des responsables (Maintainer
ou
Uploader
) du paquet. Ainsi, l'entrée du journal de
modification (changelog
) d'un envoi de
QA
commence par la ligne :
* QA upload.
Si vous voulez faire une NMU, et que le responsable ne semble pas actif, il
est judicieux de vérifier le paquet pour voir s'il est orphelin (cette
information est disponible sur la page du PTS relative au paquet). Lors d'un
premier envoi de QA
sur un paquet orphelin, veuillez
positionner le responsable à « Debian QA Group
<packages@qa.debian.org>
». La liste actuelle des paquets
orphelins dont le responsable n'a pas encore été modifié est disponible en
https://qa.debian.org/orphaned.html.
Instead of doing a QA upload, you can also consider adopting the package by making yourself the maintainer. You don't need permission from anybody to adopt an orphaned package; you can just set yourself as maintainer and upload the new version (see Section 5.9.5, « Adoption de paquet »).
Sometimes you are fixing and/or updating a package because you are member of
a packaging team (which uses a mailing list as Maintainer
or Uploader
; see Section 5.13, « Maintenance collective »)
but you don't want to add yourself to Uploaders
because
you do not plan to contribute regularly to this specific package. If it
conforms with your team's policy, you can perform a normal upload without
being listed directly as Maintainer
or
Uploader
. In that case, you should start your changelog
entry with the following line:
* Team upload.
Package salvaging is the process by which one attempts to save a package that, while not officially orphaned, appears poorly maintained or completely unmaintained. This is a weaker and faster procedure than orphaning a package officially through the powers of the MIA team. Salvaging a package is not meant to replace MIA handling, and differs in that it does not imply anything about the overall activity of a maintainer. Instead, it handles a package maintainership transition for a single package only, leaving any other package or Debian membership or upload rights (when applicable) untouched.
Note that the process is only intended for actively taking over
maintainership. Do not start a package salvaging process when you do not
intend to maintain the package for a prolonged time. If you only want to fix
certain things, but not take over the package, you must use the NMU process,
even if the package would be eligible for salvaging. The NMU process is
explained in Section 5.11, « Mises à jour indépendantes (NMU
) ».
Another important thing to remember: It is not acceptable to hijack others' packages. If followed, this salvaging process will help you to ensure that your endeavour is not a hijack but a (legal) salvaging procedure, and you can counter any allegations of hijacking with a reference to this process. Thanks to this process, new contributors should no longer be afraid to take over packages that have been neglected or entirely forgotten.
The process is split into two phases: In the first phase you determine whether the package in question is eligible for the salvaging process. Only when the eligibility has been determined you may enter the second phase, the actual package salvaging.
For additional information, rationales and FAQs on package salvaging, please visit the Salvaging Packages page on the Debian wiki.
A package becomes eligible for salvaging when it has been neglected by the current maintainer. To determine that a package has really been neglected by the maintainer, the following indicators give a rough idea what to look for:
NMUs, especially if there has been more than one NMU in a row.
Bugs filed against the package do not have answers from the maintainer.
Upstream has released several versions, but despite there being a bug entry asking for it, it has not been packaged.
There are QA issues with the package.
You will have to use your judgement as to whether a given combination factors constitutes neglect; in case the maintainer disagrees they have only to say so (see below). If you're not sure about your judgement or simply want to be on the safe side, there is a more precise (and conservative) set of conditions in the Package Salvaging wiki page. These conditions represent a current Debian consensus on salvaging criteria. In any case you should explain your reasons for thinking the package is neglected when you file an Intent to Salvage bug later.
If and only if a package has been determined to be eligible for package salvaging, any prospective maintainer may start the following package salvaging procedure.
Open a bug with the severity "important" against the package in question,
expressing the intent to take over maintainership of the package. For this,
the title of the bug should start with ITS:
package-name
[5]. You may
alternatively offer to only take co-maintenance of the package. When you
file the bug, you must inform all maintainers, uploaders and if applicable
the packaging team explicitly by adding them to
X-Debbugs-CC
. Additionally, if the maintainer(s) seem(s)
to be generally inactive, please inform the MIA team by adding
mia@qa.debian.org
to X-Debbugs-CC
as
well. As well as the explicit expression of the intent to salvage, please
also take the time to document your assessment of the eligibility in the bug
report, for example by listing the criteria you've applied and adding some
data to make it easier for others to assess the situation.
In this step you need to wait in case any objections to the salvaging are
raised; the maintainer, any current uploader or any member of the associated
packaging team of the package in question may object publicly in response to
the bug you've filed within 21 days
, and this terminates
the salvaging process.
The current maintainers may also agree to your intent to salvage by filing a
(signed) public response to the the bug. They might propose that you become
a co-maintainer instead of the sole maintainer. On team maintained
packages, a member of the associated team can accept your salvaging proposal
by sending out a signed agreement notice to the ITS bug, alternatively
inviting you to become a new co-maintainer of the package. The team may
require you to keep the package under the team's umbrella, but then may ask
or invite you to join the team. In any of these cases where you have
received the OK to proceed, you can upload the new package immediately as
the new (co-)maintainer, without the need to utilise the
DELAYED
queue as described in the next step.
After the 21 days delay, if no answer has been sent to the bug from the
maintainer, one of the uploaders or team, you may upload the new release of
the package into the DELAYED
queue with a minimum delay
of seven days
. You should close the salvage bug in the
changelog and you must also send an nmudiff to the bug ensuring that copies
are sent to the maintainer and any uploaders (including teams) of the
package by CC'ing
them in the mail to the BTS.
During the waiting time of the DELAYED
queue, the
maintainer can accept the salvaging, do an upload themselves or (ask to)
cancel the upload. The latter two of these will also stop the salvaging
process, but the maintainer must reply to the salvaging bug with more
information about their action.
« Maintenance collective » est un terme décrivant le partage des devoirs de
la maintenance d'un paquet Debian par plusieurs personnes. Cette
collaboration est presque toujours une bonne idée car il en résulte
généralement une meilleure qualité et un temps de correction de bogues plus
court. Il est fortement recommandé que les paquets de priorité
standard
ou qui font partie de la base aient des
co-responsables.
Habituellement, il y a un responsable principal et un ou plusieurs
co-responsables. Le responsable principal est la personne dont le nom est
indiqué dans le champ Maintainer
du fichier
debian/control
. Les co-responsables sont tous les
autres responsables, normalement listés dans le champ
Uploaders
du fichier debian/control
.
Dans sa forme la plus simple, ajouter un nouveau co-responsable est assez facile :
Set up the co-maintainer with access to the sources you build the package
from. Generally this implies you are using a network-capable version
control system, such as CVS
or
Subversion
. Alioth (see Section 4.12, « FusionForge
pour Debian : Alioth
»)
provides such tools, amongst others.
ajouter les nom et adresse correctes du co-responsable au champ
Uploaders
dans le premier paragraphe du fichier
debian/control
;
Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
Using the PTS (Section 4.10, « The Debian Package Tracker »), the co-maintainers should subscribe themselves to the appropriate source package.
Une autre forme de maintenance collective est une maintenance en équipe,
recommandée si vous gérez plusieurs paquets avec le même groupe de
développeurs. Dans ce cas, les champs de responsable
(Maintainer
et Uploaders
) de chaque
paquet doivent être gérés avec attention. Il est conseillé de choisir parmi
les deux possibilités suivantes :
placer un membre de l'équipe comme responsable principal du paquet dans le
champ Maintainer
. En Uploaders
, placer
l'adresse de la liste de diffusion, et les membres de l'équipe qui
s'occupent du paquet ;
Put the mailing list address in the Maintainer
field. In
the Uploaders
field, put the team members who care for
the package. In this case, you must make sure the mailing list accepts bug
reports without any human interaction (like moderation for non-subscribers).
En tout cas, il faut éviter de placer automatiquement tous les membres de
l'équipe dans le champ Uploaders
. Cela encombre la vue
d'ensemble des paquets d'un développeur (voir Section 4.11, « Vue d'ensemble des paquets d'un développeur ») avec
des paquets dont il ne s'occupe pas vraiment, et donne la fausse impression
d'un bon suivi. De même, les membres de l'équipe n'ont pas besoin de
s'ajouter dans le champ Uploaders
pour faire un envoi
ponctuel, ils peuvent le faire en « envoi d'équipe » (voir Section 5.11.7, « NMU et envoi d'équipe »). En revanche, c'est une mauvaise idée de garder
un paquet avec seulement l'adresse de la liste de diffusion dans le champ
Maintainer
et sans Uploaders
.
Les paquets sont habituellement installés dans la distribution
testing
après avoir subi suffisamment de tests dans
unstable
.
Ils doivent être en synchronisation pour toutes les architectures et ne
doivent pas avoir de dépendances qui les rendraient non installables ; ils
doivent également être exempts de bogue critique pour la publication
(« release-critical
») au moment où ils sont installés
dans testing
. Ainsi, testing
devrait
toujours être prête à devenir une version candidate pour la
publication. Veuillez voir ci-dessous pour les détails.
Les scripts de mise à jour de la distribution testing
sont exécutés deux fois par jour, juste après l'installation des paquets mis
à jour ; ces scripts sont appelés britney
. Ils fabriquent
les fichiers Packages
pour la distribution
testing
, mais ils le font d'une manière intelligente pour
éviter toute incohérence et essayer de n'utiliser que des paquets sans
bogue.
L'inclusion d'un paquet d'unstable
est soumise aux
conditions suivantes :
le paquet doit avoir été disponible dans unstable
depuis
deux, cinq ou dix jours selon l'urgence de l'envoi (élevée, moyenne ou
basse). Veuillez noter que cette urgence est « collante »
(« sticky
»), ce qui signifie qu’il est tenu compte de
l'urgence la plus élevée des envois depuis la précédente transition dans
testing
.
il ne doit pas introduire de nouveau bogue critique pour la publication
(« RC bug
» affectant la version disponible dans
unstable
, mais pas celle de testing
) ;
il doit être disponible pour toutes les architectures pour lesquelles il a
déjà été construit dans unstable
. dak ls permet de vérifier cette information ;
il ne doit pas casser les dépendances d'un paquet déjà disponible dans
testing
;
les paquets dont il dépend doivent soit être déjà disponibles dans
testing
, soit être acceptés dans
testing
au même moment (et ils doivent remplir tous les
critères nécessaires) ;
l'état du projet. C'est-à-dire que les transitions automatiques sont
arrêtées pendant le freeze (gel) de la distribution
testing
.
Pour savoir si un paquet a progressé ou non dans testing
,
veuillez voir la sortie du script de testing
sur la
page web de la distribution
testing
ou utilisez le programme
grep-excuses du paquet devscripts
. Pour rester informé de la
progression de vos paquets dans testing
, vous pouvez
facilement le mettre dans une crontab(5).
Le fichier update_excuses
ne donne pas toujours la
raison précise pour laquelle un paquet est refusé ; il peut être nécessaire
de la chercher soi-même en regardant ce qui serait cassé avec l'inclusion du
paquet. La page web de la distribution
testing
donne plus d'informations sur les
problèmes courants pouvant occasionner cela.
Parfois, certains paquets n'entrent jamais dans testing
parce que le jeu des inter-relations est trop compliqué et ne peut être
résolu par le script. Voir ci-dessous pour des détails.
Some further dependency analysis is shown on https://release.debian.org/migration/ — but be warned: this page also shows build dependencies that are not considered by britney.
For the testing
migration script, outdated means: There
are different versions in unstable
for the release
architectures (except for the architectures in fuckedarches; fuckedarches is
a list of architectures that don't keep up (in
update_out.py
), but currently, it's empty). Outdated
has nothing whatsoever to do with the architectures this package has in
testing
.
Considérons cet exemple :
alpha | arm | |
---|---|---|
testing | 1 | - |
unstable | 1 | 2 |
The package is out of date on alpha
in
unstable
, and will not go to
testing
. Removing the package would not help at all; the
package is still out of date on alpha
, and will not
propagate to testing
.
Cependant, si ftp-master
supprime un paquet
d'unstable
(ici pour arm
) :
alpha | arm | hurd-i386 | |
---|---|---|---|
testing | 1 | 1 | - |
unstable | 2 | - | 1 |
Dans ce cas, le paquet est synchronisé pour toutes les architectures de
version dans unstable
(et l'architecture supplémentaire
hurd-i386
ne compte pas car ce n'est pas une architecture
de publication).
Quelquefois, la question est soulevée de savoir s'il est possible de
permettre à des paquets de passer dans testing
alors
qu'ils ne sont pas encore construits pour toutes les architectures :
non. Simplement non. (Excepté si vous êtes responsable de glibc ou
équivalent).
Parfois, un paquet est supprimé pour permettre l'inclusion d'un autre
paquet : cela ne se produit que pour permettre à un
autre paquet d'entrer, ce dernier doit être prêt pour
tous les autres critères. Par exemple, si un paquet a
ne
peut pas être installé avec la nouvelle version de b
,
alors a
peut être supprimé pour permettre l'entrée de
b
.
Of course, there is another reason to remove a package from
testing
: it's just too buggy (and having a single RC-bug
is enough to be in this state).
De plus, si un paquet a été supprimé d'unstable
et que
plus un seul paquet de testing
n'en dépend, il sera alors
automatiquement supprimé.
Une situation mal gérée par britney
est si un paquet
a
dépend de la nouvelle version d'un paquet
b
et vice versa.
Voici un exemple :
testing | unstable | |
---|---|---|
a | 1; depends: b=1 | 2; depends: b=2 |
b | 1; depends: a=1 | 2; depends: a=2 |
Aucun des paquets a
et b
ne sera
considéré pour mise à jour.
Actuellement, cela nécessite un coup de pouce manuel de l'équipe de
publication. Veuillez les contacter à l'adresse <debian-release@lists.debian.org>
si
cela se produit pour l'un de vos paquets.
Généralement, l'état d'un paquet dans testing
ne change
rien pour la transition de la prochaine version
d'unstable
vers testing
, avec deux
exceptions : si le nombre de bogues critiques pour la publication du paquet
diminue, le paquet peut migrer même s'il a encore des bogues critiques pour
la publication. La seconde exception est que si la version du paquet dans
testing
est désynchronisée entre les différentes
architectures, alors toute architecture peut être mise à jour vers la
version du paquet source ; cependant, cela ne peut se produire que si le
paquet a été précédemment forcé, si l'architecture est dans
fuckedarches
ou s'il n'y avait pas du tout de paquet
binaire de cette architecture présent dans unstable
lors
de la migration dans testing
.
En résumé, cela signifie : la seule influence qu'un paquet de
testing
a sur la nouvelle version du même paquet est que
la nouvelle version peut entrer plus facilement.
Suivent quelques informations sur le fonctionnement de
britney
.
Les paquets sont examinés pour savoir si ce sont des candidats
valables. Cela génère les dispenses de mise à jour (« update
excuses
»). Les raisons habituelles pour lesquelles un paquet
n'est pas considéré sont la jeunesse du paquet, le nombre de bogues
critiques pour la publication et la désynchronisation pour certaines
architectures. Pour cette partie de britney
, les
responsables de publication ont des marteaux de toute taille, appelés coups
de pouce (« hints », voir ci-dessous) pour forcer britney
à examiner un paquet.
Maintenant, la partie la plus complexe se produit :
britney
tente de mettre à jour testing
avec des candidats valables. Pour ce faire, britney
essaye d'ajouter chaque candidat valable à la distribution
testing
. Si le nombre de paquets non installables dans
testing
n'augmente pas, le paquet est accepté. À partir
de là, le paquet accepté est considéré comme partie de
testing
, de telle sorte qu'il sera considéré dans les
tests suivants d'installabilité. Avant et après cette partie, certains coups
de pouce (« hints ») de l'équipe de publication sont traités.
Pour obtenir plus de précisions, vous pouvez consulter https://ftp-master.debian.org/testing/update_output/.
Les coups de pouce (« hints ») sont disponibles sur https://ftp-master.debian.org/testing/hints/, qui contient aussi
une description.
Avec les coups de pouce, l'équipe en charge de la publication de Debian peut
bloquer ou débloquer des paquets, faciliter ou forcer le passage de paquets
dans testing
, enlever des paquets de
testing
, approuver des envois vers testing-proposed-updates ou outrepasser l'urgence.
La distribution testing
est remplie de paquets en
provenance d'unstable
selon des règles expliquées
ci-dessus. Cependant, dans certains cas, il est nécessaire d'envoyer des
paquets construits seulement pour testing
. Pour cela,
vous pouvez envoyer vos paquets vers
testing-proposed-updates
.
Keep in mind that packages uploaded there are not automatically processed;
they have to go through the hands of the release manager. So you'd better
have a good reason to upload there. In order to know what a good reason is
in the release managers' eyes, you should read the instructions that they
regularly give on <debian-devel-announce@lists.debian.org>
.
Vous ne devriez pas envoyer de paquet à
testing-proposed-updates
quand vous pouvez le mettre à
jour par unstable
. Si vous ne pouvez faire autrement (par
exemple, parce que vous avez une nouvelle version de développement dans
unstable
), vous pouvez utiliser cette facilité, mais il
est recommandé de demander l'autorisation des responsables de publication
auparavant. Même si un paquet est gelé, des mises à jour par
unstable
sont possibles si l'envoi dans
unstable
ne crée pas de nouvelles dépendances.
Version numbers are usually selected by appending
+deb
X
uY
,
where X
is the major release number of Debian and
Y
is a counter starting at 1
.
e.g. 1:2.4.3-4+deb9u1
.
Veuillez vous assurer n'avoir oublié aucun des éléments suivants lors de votre envoi :
vérifiez que le paquet doit vraiment aller dans
testing-proposed-updates
, et ne peut pas passer par
unstable
;
vérifiez n'avoir intégré qu'un minimum de changements ;
vérifiez avoir ajouté une explication appropriée dans le journal de
modification (changelog
) ;
Make sure that you've written the testing code
name (e.g. buster
) into your target
distribution;
vérifiez avoir construit et testé votre paquet dans
testing
, et non dans unstable
;
vérifiez que le numéro de version est plus élevé que les versions de
testing
et testing-proposed-updates
,
et moins élevé que celle de unstable
;
après l'envoi et la construction réussie sur toutes les plates-formes,
contactez l'équipe de publication à <debian-release@lists.debian.org>
et demandez-leur
d'approuver votre envoi.
Tous les bogues de gravité assez élevée sont par défaut considérés comme
bloquant l'intégration du paquet dans la version stable ; actuellement, ce
sont les bogues critical
(critique),
grave
(grave) et serious
(sérieux).
Certains bogues sont supposés avoir un impact sur la probabilité d'un paquet
a être diffusé dans la version stable
de Debian : en
général, si un paquet a des bogues bloquants, il n'ira pas dans
testing
, et par conséquent, ne pourra pas être diffusé
dans stable
.
The unstable
bug count comprises all release-critical
bugs that are marked to apply to
package
/version
combinations available in unstable
for a release
architecture. The testing
bug count is defined
analogously.
La structure des archives de la distribution est faite de telle façon
qu'elles ne peuvent contenir qu'une version d'un paquet ; un paquet est
défini par son nom. Donc, quand le paquet source acmefoo
est installé dans testing
avec ses paquets binaires
acme-foo-bin
, acme-bar-bin
,
libacme-foo1
et libacme-foo-dev
,
l'ancienne version est supprimée.
However, the old version may have provided a binary package with an old
soname of a library, such as libacme-foo0
. Removing the
old acmefoo
will remove libacme-foo0
,
which will break any packages that depend on it.
Evidently, this mainly affects packages that provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <=, or << varieties.
When the set of binary packages provided by a source package changes in this
way, all the packages that depended on the old binaries will have to be
updated to depend on the new binaries instead. Because installing such a
source package into testing
breaks all the packages that
depended on it in testing
, some care has to be taken now:
all the depending packages must be updated and ready to be installed
themselves so that they won't be broken, and, once everything is ready,
manual intervention by the release manager or an assistant is normally
required.
Si vous avez des problèmes avec des groupes compliqués de paquets comme
cela, demandez de l'aide sur <debian-devel@lists.debian.org>
ou <debian-release@lists.debian.org>
.
[3] Reportez-vous à la Charte Debian
(« Debian Policy Manual
») pour savoir dans
quelle section un paquet doit être classé.
[4] Par le passé, ces NMU utilisaient le numéro de troisième niveau de la partie Debian de la révision pour indiquer l'état de leur recompilation particulière ; cependant, cette syntaxe était ambiguë pour les paquets natifs et ne permettait pas d'ordonner correctement les NMU de recompilation particulière, les NMU source et les NMU de sécurité sur le même paquet, elle a donc été abandonnée en faveur de cette nouvelle syntaxe.
[5] ITS is shorthand for "Intend to Salvage"