Template:Bandeau multi-langues-fr
Contents
- 1 Pourquoi ne sont-ils pas activés ?
- 2 Que signifient les différentes appellations des dépôts ?
- 3 Qu'entend-on réellement par Activé et M.à J. ici ?
- 4 Quels médias définir comme médias de mise à jour ?
- 5 Activer les M. à J. Testing : Le moyen le plus facile
- 6 Les activer : une méthode plus brutale
- 7 Les ajouter séparément
- 8 Comment les utiliser et les désactiver
Pourquoi ne sont-ils pas activés ?
Les mises à jour à partir des dépôts Testing ne sont pas activées par défaut; vous pouvez faire des installations nouvelles provenant de ceux-ci, mais pas mettre à jour un paquetage existant à partir des Testing. La simple raison est que le logiciel contenu n'a pas été vérifié. Bien que les packagers 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 QA 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'activés.
- media 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.
- media Debug
- Les media 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.
- media 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 media vers un autre) par les Sysadmins.
- media Updates Testing
- Ils font partie de ceux qui nous intéressent ici. Les medias Testing contiennent les paquetages mis à jour qui attendent la validation QA. Les paquetages y restent jusqu'à ce qu'ils soient "poussés" dans les media Updates pertinents par l'équipe Sysadmin.
- media 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 des fonctionnalités nouvelles et désirées mais peuvent aussi apporter des problèmes nouveaux et 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.
- media 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 medias Backports adéquats .
Pour plus d'informations, consulter Gestion des logiciels
Qu'entend-on réellement par 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 médias Release . Les paquetages mis à jour se trouvent dans les médias 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 médias 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 média Updates .
Il y a aussi des médias que la plupart des utilisateurs réguliers n'auront pas à utiliser , comme les médias 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 médias Debug (qui contiennent des informations de débogage technique requis par le débogage des logiciels comme gdb). Tous ces médias sont ajoutés pour vous par défaut mais seulement certains sont configurés pour être utilisés. Tout media Activé sera utilisé et les autres seront ignorés.
Quels médias définir comme médias de mise à jour ?
Vous pourriez trouver suffisant que les médias 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 médias Updates Testing, mais nous ne voulons pas que ceux-ci soient activés par défaut car seuls sont installés depuis ces médias Updates Testing les paquetages dont nous avons besoin pour pouvoir tester une mise à jour particulière.Vous ne devez pas laisser les médias 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 mises à jour sur les médias 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 .
Les activer : 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 . Simplement ajoutez le mot update sur une ligne séparée dans les sections pertinentes. Plusieurs sections doivent déjà comporter le mot update comme 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 médias. 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"
N'oubliez pas de désactiver le média 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 média testing activé sera installé
Pour vous faciliter la tâche, il y a quelques alias utiles que vous pouvez utiliser.
Return to the QA portal