Certes, ATrmps a réalisé un rpm pour les codecs. J'indique ci-après les trois méthodes possibles.
1- IMPLANTATION DES CODECs DEPUIS UNE ARCHIVE:
Les CODECs sont pris à la source (ils sont maintenus par mplayer)
1- on ouvre une console avec les droits root (le reste des actions est réalisé avec les droits root):
$ su -
$ password: <saisir le mot de passe root>
2- on créé deux répertoires pour recevoir les CODECs:
# mkdir /usr/local/lib/codecs/ (le répertoire-cible)
# mkdir /tmp (un répertoire de manoeuvre, temporaire)
3- on télécharge l'archive dans le répertoire de manoeuvre:
# cd /tmp
# wget http://www.mplayerhq.hu/MPlayer/releases/codecs/all-20050412.tar.bz2
4- on décompacte l'archive et on déplace le contenu obtenu dans le répertoire-cible:
# tar xvfj *.tar.bz2
# cd all-20050412
# cp *.* /usr/local/lib/codecs/
5- on se positionne dans le répertoire-cible et on rend les programmes exécutables:
# cd /usr/local/lib/codecs/
# chmod 755 /usr/local/lib/codecs/*
6- on créé un lien symbolique entre le répertoire-cible et un répertoire utilisé par Xine et Mplayer pour la recherche des CODECs:
# ln -s /usr/local/lib/codecs /usr/lib/win32
La modification des CODECs sera toujours réalisée dans le répertoire cible créé (/usr/local/lib/codecs/)
7- on supprime le répertoire temporaire:
# rm -rf /temp
8- on reboote le système:
# shutdown -r now
2- IMPLANTATION DES CODECs DEPUIS UN RPM SANS MODIFICATION DES DEPOTS:
Le rpm est réalisé par ATrpms; il n'est pas constitué à partir de la dernière version de l'archive mais semble fonctionner d'après le forum:
1- on ouvre une console avec les droits root:
$ su -
$ password: <saisir le mot de passe root>
2- on télécharge le rpm:
# wget http://dl.atrpms.net/all/w32codec-1.0_20041107-11.at.i386.rpm
3- on l'installe:
# rpm -Uhv w32codec-1.0_20041107-11.at.i386.rpm
3- IMPLANTATION DES CODECs DEPUIS UN RPM EN UTILISANT LE DEPOT ATRPMS:
On créé le dépôt en question mais on l'inhibera par défaut, pour des raisons d'incompatibilité avec les dépôts de référence.
On se référera à
l'excellent tutorial de Mr Tom, le dépôt étant inhibé.
1- on ouvre une console avec les droits root:
$ su -
$ password: <saisir le mot de passe root>
2- on créé le dépôt:
# gedit /etc/yum.repos.d/atrpms.repo
Dans l'éditeur de texte, on saisit:
[atrpms]
name=ATrpms for Fedora Core $releasever stable
baseurl=http://apt.atrpms.net/fedora/$releasever/en/$basearch/at-stable
mirrorlist=http://ftp-stud.fht-esslingen.de/atrpms/download.atrpms.net/fedora/$releasever/en/$basearch/at-stable
mirrorlist=http://wftp.tu-chemnitz.de/pub/linux/ATrpms/fedora/$releasever/en/$basearch/at-stable
enabled=0
gpgcheck=1
On sauvegarde le fichier et on quitte.
On implante la clé publique pour la vérification de signature des rpm:
#rpm --import http://atrpms.net/RPM-GPG-KEY.atrpms
3- on implante le rpm des CODECs:
# yum --enablerepo=atrpms install W32codec*
4- REMARQUES FINALES:
La méthode 1 est incompatible des autres méthodes; la méthode 2 et la méthode 3 sont entièrement compatibles car elles manipulent des rpm.
La recherche de simplicité pousse au choix de la méthode 2. Un seule réserve peut être exprimée qui concerne le recours à un rpm réalisé par un dépôt tiers.
Sans entrer dans un troll infernal, je rappelle les pbs de compatibilité rencontrés et je cite
S FINLEY (special warning regarding mixing incompatible repositories for up2date, yum, and apt):
"You should not use the livna.org repository and possibly the fedora extras repository (which derives from the old fedora.us repository) in conjunction with the dag/freshrpms/dries/newrpms/PlanetCCRMA (RPMforge) collection of rpms in your configuration files for automatic updates. Use one group or the other but not both. You should be made aware that there are two ?schools? of rpm packagers for Fedora Core extra applications. One group consists of the livna.org/fedora.us repositories and the other group consists of the dag/freshrpms/dries/newrpms/PlanetCCRMA (RPMforge) repositories. One of the most common causes of errors and failures in a new Fedora Core installation has been the mixing of these two incompatible repository collections for automatic updates. These two groups of rpm repositories have been for the most part mutually incompatible in the past and in some cases have been known to cause serious errors in Fedora Core installations if used together. It is unfortunate that these two groups have not found some common ground for consensus and have not gotten together and made their repositories compatible with one another. ..."
Traduction: "Vous ne devez pas utiliser le dépôt livna.org -et probablement le dépôt fedora extras repository (qui dérive de l'ancien depôt fedora.us)- et les collections de rpm des dépôts dag/freshrpms/dries/newrpms/PlanetCCRMA (RPMforge) dans vos fichiers de configuration pour les mises à jour automatiques. Utilisez l'un ou l'autre de ces groupes mais pas les deux. Vous devez être conscients qu'il existe deux écoles de packagers de rpm pour les logiciels Fedora Core non compris dans la distribution d'origine. L'un de ces groupes est composé de livna.org/fedora.us , l'autres, de dag/freshrpms/dries/newrpms/PlanetCCRMA (RPMforge). L'une des principales causes d'erreurs et d'échecs au sein de la nouvelle installation Fedora Core tient au mixage de ces deux sources incompatibles pour les mises à jour automatiques. Ces deux groupes de dépôts ont été pour l'essentiel mutuellement incompatibles et en certains cas, ont été identifiés comme la cause d'erreurs sérieuses lors des installations Fedora Core, lorsqu'ils étaint utilisés ensemble. Il est regrettable que ces deux groupes n'ont pas trouvé de terrain d'entente et ne se sont pas unis pour rendre leurs dépôts mutuellement compatibles..."
