Wiki » Activer les dépôts Testing-fr

Autres langues Deutsch ; English ; Français  ; Nederlands ;

Pourquoi les dépôts Testing sont désactivés ?

Les mises à jour à partir des dépôts Testing ne sont pas activées par défaut ; vous pouvez faire des nouvelles installations provenant de ceux-ci, mais vous ne pouvez pas mettre à jour un paquetage existant à partir des dépôts Testing. La simple raison est que le logiciel contenu n’a pas été vérifié. Bien que les empaqueteurs fassent habituellement un excellent travail en vérifiant ailleurs qu’ils n’ont rien cassé ou induit des problèmes, ici simplement le paquetage n’a pas été testé.

C’est là que l’équipe Assurance Qualité intervient !

Que signifient les différentes appellations des dépôts ?

Vous avez sans doute remarqué que vous avez bien plus de dépôts désactivés que d’activer.

dépôt Release

C’est de ceux-ci que viendront la plupart des paquetages que nous installerons en premier. Ils contiennent tous les paquetages tels qu’ils étaient au moment de la sortie de la distribution.

dépôt Debug

Les dépôts Debug contiennent les informations de corrections des différents paquetages. En réalité, nous n’avons pas besoin de nous préoccuper de ceux-ci : bien qu’ils soient utiles pour déboguer un paquetage qui dysfonctionne, vous n’aurez généralement pas besoin de faire des mises à jour à partir de Debug, seulement des installations.

dépôt Updates

Ils contiennent tous les paquetages mis à jour qui ont été acceptés par la validation QA et ont été « poussés » (déplacés d’un dépôt vers un autre) par les administrateurs système.

dépôt Updates Testing

Ils font partie de ceux qui nous intéressent ici. Les dépôts Testing contiennent les paquetages mis à jour qui attendent la validation QA. Les paquetages y restent jusqu’à ce qu’ils soient « poussés » dans les dépôts Updates pertinents par l’équipe Sysadmin.

dépôt Backports

les Backports sont les nouvelles moutures des paquetages qui n’ont pas réellement leur place dans la version en cours. Ils peuvent souvent apporter de nouvelles fonctionnalités désirées, mais peuvent aussi apporter de nouveaux problèmes indésirables. Bien qu’ils passent avec succès la procédure de validation QA, il se peut qu’ils entrent en conflit avec les autres paquetages du système et, dans une large mesure, demeurent non supportés.

dépôt Backports Testing

C’est là que les nouveaux paquetages rétro-portés sont placés jusqu’à ce qu’ils passent la validation QA pour être ensuite transférés dans les dépôts Backports adéquats.

Pour plus d’informations, consulter Gestion des logiciels

Que signifient concrètement les termes Activé et M.à J. ici ?

Comme vous pouvez le voir sur le tableau ci-dessus, les paquetages mis à jour sont bien séparés des originaux dans les dépôts Release. Les paquetages mis à jour se trouvent dans les dépôts Updates. Par exemple Core Release and Core Updates. Les paquetages de Core Updates sont les versions mises à jour des paquetages de Core Release.

Afin d’accélérer le processus d’installation de mises à jour, seuls les dépôts marqués comme contenant des mises à jour sont vérifiés pour les nouvelles versions des logiciels que vous avez installés. C’est ce qu’on entend par la définition de dépôt Updates.

Il y a aussi des dépôts que la plupart des utilisateurs réguliers n’auront pas à utiliser, comme les dépôts Testing (qui est l’endroit où les paquetages candidats à la mise à jour sont construits et testés avant d’être propulsés comme Updates ou les dépôts Debug (qui contiennent des informations de débogage technique requis par le débogage des logiciels comme gdb). Tous ces dépôts sont ajoutés pour vous par défaut, mais seulement certains sont configurés pour être utilisés. Tous les dépôts Activés seront utilisés et les autres seront ignorés.

Quels dépôts définir comme dépôts de mise à jour ?

Vous pourriez trouver suffisant que les dépôts nommés Updates soient déjà activés pour les mises à jour, mais vous pouvez avoir besoin d’activer aussi Nonfree Updates et Tainted Updates si ça n’est pas encore fait. Pour nos projets dans l'Équipe QA nous devons pouvoir tester les mises à jour depuis les dépôts Updates Testing. Toutefois, nous ne voulons pas que ceux-ci soient activés par défaut, car seuls sont installés depuis ces dépôts Updates Testing les paquetages dont nous avons besoin pour pouvoir tester une mise à jour particulière. Vous ne devez pas laisser les dépôts Updates Testing activés en permanence.

Voici les dépôts supplémentaires qu’on peut activer comme mises à jour :

• Core Updates Testing
• Nonfree Updates Testing
• Tainted Updates Testing
• Core 32bit Updates Testing (x86_64 seulement)

Vous ne devez pas activer les Updates sur les dépôts Release !

Activer les M. à J. Testing : Le moyen le plus facile

Un moyen simple de les activer est d’utiliser le commutateur 'expert' comme ci-dessous :

drakrpm-edit-media --expert

Cochez la colonne 'M.à J.' en face des dépôts listés ci-dessus. Ils apparaîtront comme sur l’image ci-dessous, avec une coche dans la colonne M.à.J pour les dépôts (Core, Nonfree, Tainted) Updates Testing.

Activer les M. à J. Testing : Une méthode plus brutale

Vous pouvez aussi utiliser la ligne de commande et éditer manuellement avec précaution le fichier /etc/urpmi/urpmi.cfg, et ajouter l’option M.à.J. aux dépôts testing. Pour modifier le fichier, vous aurez besoin de vous connecter comme super utilisateur, la prudence est donc de mise. Ajoutez simplement le mot « update » sur une ligne séparée dans les sections pertinentes. Plusieurs sections doivent déjà comporter le mot update par exemple Core Updates, ce qui devrait vous donner une idée sur la façon de procéder pour les sections Testing.

Par exemple :

Core\ Updates\ Testing { ignore key-ids: 80420f66 mirrorlist: $MIRRORLIST update with-dir: media/core/updates_testing }

Si vous avez le moindre doute, ne faites aucune modification au fichier !

Les ajouter séparément

Vous pouvez aussi ajouter séparément les dépôts Testing manuellement à partir de la ligne de commande et permettre leur activation aux mises à jour en utilisant la commande urpmi.addmedia avec l’option --update

La syntaxe pour ce faire est la suivante :

urpmi.addmedia nom_à_choisir --update $PROTOCOL://$MIRROR/path/to/Mageia/$ARCH/media/$MEDIA/$REPOSITORY_testing

Par exemple :

urpmi.addmedia CUTesting --update http://ftp.belnet.be/mirror/mageia/distrib/1/i586/media/core/updates_testing

ou

urpmi.addmedia NFBTesting --update http://twiska.zarb.org/mageia/distrib/1/x86_64/media/nonfree/backports_testing

Assurez-vous de choisir l’architecture qui convient à votre installation. Le nom que vous choisissez d’utiliser est à votre entière convenance. Une liste des miroirs pour Mageia est disponible ici.

Comment les utiliser et les désactiver

Une fois que vous avez activé les mises à jour à partir des dépôts Testing, elles peuvent être activées ou désactivées en utilisant le gestionnaire de dépôts. Vous pouvez y accéder par une option dans rpmdrake ou via le Centre de Contrôle de Mageia, Configurer les sources pour installer et mettre à jour des logiciels.

Pour le lancer depuis la ligne de commande, saisir edit-urpm-sources.pl connecté en super utilisateur.

Autre possibilité, utiliser la commande urpmi.update comme ci-dessous :

Pour activer Core Updates Testing :

urpmi.update --no-ignore "Core Updates Testing"

pour désactiver :

urpmi.update --ignore "Core Updates Testing"

Pensez à désactiver le dépôt une fois que vous avez installé la mise à jour à tester, sinon, lors des mises à jour système régulières, tout ce qui se trouve dans le dépôt testing activé sera installé.

Pour vous faciliter la tâche, il y a quelques alias utiles que vous pouvez utiliser.

Retour vers le Portail de l’équipe AQ