Jusqu'à preuve du contraire, aucune option de ligne de commande urpmi ne permet de forcer une réinstallation.
La réponse reste invariablement "Tout est déjà installé".

Pour y remédier, j'ai testé l'installation intermédiaire d'une version précédente :

# urpmq -ar coreutils
coreutils-5.0-6mdk|coreutils-5.0-6.1.92mdk
# urpmi --force coreutils-5.0-6mdk && urpmi coreutils-5.0-6.1.92mdk

Ça fonctionne, mais nécessite le téléchargement d'un paquet supplémentaire et peut poser problème avec les dépendances.

J'ai aussi testé la désinstallation virtuelle :

# rpm -e --justdb --nodeps coreutils
# urpmi coreutils

Là l'inconvénient c'est que urpmi fait une nouvelle installation, pas une mise à jour. Du coup il tique un peu sur les fichiers de config déjà existants et rajoute des rpmnew.

Reste le téléchargement et l'installation à la main, mais urpmi est là pour nous éviter ça, pas vrai ?

Bref rien de vraiment satisfaisant.
Vous avez une meilleure solution ?
Un vrai --force ça serait tellement bien...

NB: Les motifs de réinstallation sont nombreux, là n'est pas la question.
Dans mon cas il s'agit d'installer les catalogues de messages manquants suite à la modif de la langue dans /etc/rpm/macros

> Lire le journal (6 commentaires, moyenne: 2).

Chères lectrices, chers lecteurs,

En ma qualité d'administrateur réseau (dit comme ça, ça en jette, hein?), je suis régulièrement amené à utiliser la commande « route » (bon, là, nettement moins).
Mon problème, c'est que quand la dite commande me renvoie une cinquantaine de routes dans le désordre, je peine un peu à m'y retrouver.

J'ai déjà appris que l'on pouvait trier efficacement une liste d'adresses IP, à l'aide d'un « sort -n -t. -k1,1 -k2,2 -k3,3 -k4,4».
C'est un premier pas.
Seulement la commande « route » commence par produire 2 lignes d'entête avant d'afficher le résultat.
Ces 2 lignes se retrouvent donc dans la moulinette de « sort » et l'affichage s'en retrouve perturbé (bon, OK, rien de désastreux, mais je suis un poil perfectionniste.)

Avec un brin d'imagination, j'ai tenté la mise en série de filtres dans un shell intermédiaire :
route | (head -n 2; sort -n -t. -k1,1 -k2,2 -k3,3)
Hélas, « head » bouffe bien plus que la tête, et « sort » n'a plus rien à se mettre sous la dent. Je ne récupère que les 2 lignes d'entête.
Même résultat en utilisant un « sed -e "n;q" » à la place du « head -n 2 ».

Il s'agit visiblement d'un problème de buffer d'entrée remplit trop avidement, puisque par exemple
ls -l /usr/bin | (head -n 1; cat)me renvoie l'entête « total » suivie de la fin du « ls -l ».
À noter que « ls -l /usr/bin | (dd of=/dev/null bs=8192 count=1; cat) » me renvoie exactement le même résultat (à l'exception de l'entête bien sûr); head utilise donc un buffer de 8 Ko.

Tout cela m'amène à une interrogation plus générale: comment appliquer efficacement plusieurs filtres sur la sortie d'une même commande, l'un sur les n premières lignes, et un autre sur la suite ?

L'idée de la mise en série dans un shell tient pourtant la route, puisque par exemple route | (read a; read b; echo -e "$a\n$b"; sort -n -t. -k1,1 -k2,2 -k3,3) fonctionne.

Faut-il considérer que head, sed, et probablement d'autres sont buggés?
Ces commandes sont-elles sensées absorber plus de données qu'elles ne vont finalement en traiter?
Y aurait-il un ajustement possible quelque part pour éviter cela?

Ou peut-être que j'en demande trop à un simple shell et que ferais mieux de faire du <votre langage de script préféré> ?

Vos commentaires et avis sur la question sont les bienvenus.

> Lire le journal (22 commentaires, moyenne: 1,4).

Chers lecteurs (ben oui, je ne vais pas parler à un journal, fut-il électronique ou numérique),

Pour une raison obscure, certaines stations de mon réseau sont configurées sans nom de domaine, sans liste de recherche DNS et sans que j'y puisse quoi que ce soit.
Déjà elles accèdent bien à mon serveur DNS, faut pas leur en demander plus.

Rien de dramatique à priori.
Là où ça se corse, c'est que ces stations ont besoin d'accéder aux serveurs enregistrés dans la zone "maboite.com" en utilisant une adresse de la forme "serveur1" plutôt que "serveur1.maboite.com" (ça serait trop facile).

Il me faudrait donc définir "maboite.com" comme "zone par défaut", pour y rediriger toutes les requêtes pour des adresses sans ".", et qu'une requête pour "serveur1" renvoie les infos de "serveur1.maboite.com" (un peu dans le genre de ce que les amis de Verisign ont mis en place sur le TLD ".com", "toto" -> "toto.com").

Le serveur DNS que j'utilise actuellement et que je ne citerai pas (basé sur une vieille version de BIND) n'offre pas cette fonctionnalité.

Sauriez-vous, chers lecteurs, si BIND 8.3 (fourni avec ma Debian que j'ai) ou autre version, ou encore djbdns, voir même carrément autre chose, permet de faire ça?
Quelques trucs pour la mise en route? Quelques écueils à éviter?

Et euh... D'avance merci.

> Lire le journal (10 commentaires, moyenne: 1,2).