> rechercher selon divers filtres / installer-desintaller
Yum search. Combiné avec --enablerepo et --disablerepo, ça le fait.
Pour un recherche fine des paquets installé, rpm avec les options --queryformat --whatrequires --whatprovides est ce qu'il y a de mieux.
Avec Yum, il y a aussi le programme repoquery. Il n'interroge pas la base rpm locale (/var/lib/rpm). On retourve toute la puissance de "rpm --queryformat" + --whatrequires --whatobsoletes --whatconflicts --resolve.
> filtres avancés (exclusion de certains noms ou parties de noms par exemple)
Yum --exclude. C'est aussi configurable dans /etc/yum.conf ou via des fichiers dans /etc/yum.repo.d/
Il y a aussi les plugin yum-protectbase, plugin yum-versionlock, yum-allowdowngrade, yum-kernel-module et yum-fedorakmod.
> gestion avancée des dépendances
Heureusement. Idem pour tout le monde.
> gestion des signatures
C'est-à-dire ?
Yum vérifie si le paquet est signé, il peut aussi importer une signature (via ftp, http, etc).
> gestion des débits, splitter en transactions, splitter par poids,
Yum n'a pas.
Il y a yum-fastestmirror.
> garder/enlever du cache (et gestion avancé de celui-ci)
Yum n'a pas. Mais le cache est si petit (ici 100 Mo pour 5700 paquets info de liste de fichier comprise (alors que c'est peut utilisé)).
> passer par un proxy, utiliser ssh curl et wget
Yum a.
> synchronisation...
reposync.
> gestion de liste d' exclusion précise
???
Consédirons que Yum n'a pas.
> reconstructions
Yum n'a pas.
Mais c'est tellement con à faire avec rpm : rpm --rebuild [url]
Il y a aussi yum-builddep pour installé les *-devel nécessaires.
> gestion des architectures
Yum a. +gestion biarch.
> ne pas exécuter les scriptlets
Il y a le plugin yum-tsflags. Mais franchement, vu que yum/urpmi peut installé plusieurs paquets, c'est une mauvaise idée. Rpm le fait "--noscript --notrigger".
> installation en parallèle sur plusieurs (dizaine(s) ...) de postes.
Un serveur urpmi ?
C'est assez con à faire avec yum-updatesd (indique s'il y a des mises à jours via syslog, mail et dbus).
Peut aussi mettre à jours automatique et downloader.
Exemple d'un fichier de configuration :
# automatically install updates
do_update = no
# automatically download updates
do_download = no
# automatically download deps of updates
do_download_deps = no
Après pour l'installation automatique d'un nouveau paquet, il suffit d'installé un paquet "meta", voire un nouveau fedora-release avec un epoc supérieur à celui fournit par défaut pour être tranquille. Ainsi toute les bécanes qui point sur le dépôt on le paquet. S'il faut ajouter un programme, on ajoute un Require au paquet. S'il faut virer un programme, on ajoute un tag "obsolete".
Pas compliqué à faire pour 1, 10 ou 200 000 machines.
> gestion d' un parc d' ordinateurs
Ça m'étonnerait que urpmi fasse ça.
> gérer complètement les chroot depuis l' environnement courant.
???
yum --installroot. NB, ça aussi évidement fournit par rpm.
> utiliser un environnement différent
???
Ben avec setarch, -c [config file] et --installroot, je ne vois pas ce qu'on peut vouloir de plus.
Sous Fedora yum est utilisé pour installer des machines virtuelles (Xen).
Je ne veux pas dénigrer urpmi.
L'avantage de yum, c'est qu'il est simple. S'il faut faire des trucs compliqués, il y a d'autres programmes.
Pour Yum et un utilisateur classique, il faut une page man. Pour urpmi, il faut un site dédié à la maitrise de urpmi.
Pour ton info, compares aussi avec smart.
Red Hat sait qu'il ne peuvent pas se faire d'argent avec une distribution "communautaire" (ou alors très peu). Donc ils ont fait Fedora. Comme Fedora coûte de l'argent, il faut au moins un retour sur investissement avec les contributions externes (tests, développements, idées, etc). Or les contributeurs ne participent que si le cycle est court. La stabilité n'est vraiment pas un truc qui passionne les développeurs (=> voir Fedora Legacy qui est limite au niveau contribution). De plus contribuer alors que le fruit du labeur ne sera là que dans un an...
Le cycle de 6 mois, permet aussi de se synchroniser avec Gnome notamment. Beaucoup de projets ont maintenant un cycle de 6 mois avec un roadmap.
Au-delà des contributions extérieures, les utilisateurs de la version communautaire/gratuite seront des futurs utilisateurs de la version payante (pour Mandriva, la corporate server).
Je pense que Mandriva c'est rendu compte qu'avec un cycle long (1 ans pour la 2007), il y a peu de participation (au moins pour les 6 premiers mois du cycle).
Ajoutons la popularité d'Ubuntu grandissante par rapport à Mandriva alors qu'elle sort tous les 6 mois, on en déduit que le soit-disant avantage de sortir tout les ans n'en est pas un en fin de compte (compte aussi dans le sens "monnaie sonnante et trébuchante"). Notons que Mandriva c'est un peu cassé la gueule en terme de popularité et le passage à un cycle de 1 an ne semble en rien avoir atténué ce cassage de gueule.
Je pense que l'étape suivante pour Mandriva, sera de suivre encore un peu plus Fedora => ne pas proposer de boîte (ça coûte cher à mettre oeuvre, le processus est complexe).
Ce que j'imagine à moyen terme :
- une distribution gratuite (download uniquement donc)
- voire une distribution "boite" avec un packaging minimum (pas de doc papier, un truc à 10 ¤ maxi).
- Mandriva club.
- Mandriva corporate serveur.
A l'instar de Fedora, Mandriva va avoir un support en temps très limité.
Autre "bénéfice" pour Mandriva, mieux distinguer la Mandriva "classique" de la Mandriva Corporate Server et donc attirer des gens vers la Corporate Server qui peut-être jusque là se satisfesaient de la "classique".
Dernier truc qui moi m'a "chiffonné", c'est l'aspect "déjà vieux" de la Corporate Server 4. Elle est sortie il y a quelques semaines mais est basée sur une Mandriva 2006 (1 an d'age). Donc, Mandriva avec le couple "classique"/CS va sûrement faire comme le couple Fedora/RHEL.
Comme pour Fedora, on pourra dire que la "classique" est la version de test/alpha de la CS. Un troll est mort.
Si c'est comme je l'image, Mandriva est sûr la bonne voie. Il lui reste a communiquer avec transparence pour qu'on ne nage pas dans un grand flou.
> c'est pas la techno qui a ete recupere suite a un achat...
C'est du libre, donc inutile d'aligner du pognon pour l'avoir.
> c'etait prometeur...
C'est toujours un excellent gestionnaire de paquet.
> que urpmi etait pas aussi bien
urpmi j'ai toujours trouvé ça naze. C'est compliqué, il y a 50 commandes, etc...
OK, j'ai très très peu utilisé urpmi, mais c'est l'impression que ça donne quand on l'utilise (même peu) et quand on lit linuxfr.
> bref quel est la politique de mandriva a ce sujet ?
Je ne parlerai pas au nom de mandriva. Mais chez Fedora la question d'utiliser Smart a été posé car Smart est un très bon gestionnaire de paquet "dans son genre". Mais Smart pose plusieur problème à Fedora. Sa politique de résolutions des dépendances ne plait pas à Fedora (Fedora a de bonnes raisons de le penser). En effet, smart peut downgrader un paquet pour satisfaire des dépendances. Au moins pour des raisons de sécurité, Fedora se le refuse.
L'autre problème, et il est lié au précédent, est que smart ne passe pas rpm-lib pour voir si les dépendances sont satisfaites.
Smart ne supporte pas les groups de Fedora (fichier comps.xml ; à ne pas confondre avec les groupes de rpm).
Smart ne permet pas de mixer i386 et x86_64.
En conclusion, si on est d'accord avec le choix pour la résolution des dépendance fait par Smart, Smart est un excellent gestionnaire de paquet (et 50 fois plus simple que urpmi) et il mérite d'être plus populaire.
Avis perso.
FC6 a ajouté le cryptage. Malheureusement pas encore pour la partition racine. Je n'utilise pas le cryptage (pas pour un FS complet) dont je ne peut en dire beaucoup plus. Mais il y a un support pour monter des partitions cryptées facilement (/etc/crypttab), c'est supporté par initcript, c'est supporté par hal, gnome-volume-manager, gnome-mount, etc, mais pas encore par l'installeur (anaconda).
Du journal :
> à une époque plus lointaine GCJ et SELinux
Fedora supporte SeLinux depuis FC3 et c'est activé par défaut.
Fedora propose GCJ (java-gcj-compat, tomcat, etc) depuis assez longtemps et ça ne fait que s'améliorer. C'est aujourd'hui la référence libre du java. Aujourd'hui, bien que ça ne soit pas parfait, Le "java" de Fedora fait tourner Azureus, rssowl, eclipse, etc...
Il y a aussi un plugin java pour firefox (voir la release note).
> Idéalement, la nouvelle distribution devrait être tout à fait libre
C'est le cas de Fedora.
> stable
Stable ? Fedora est *fiable*. Par contre elle n'est pas stable (elle change beaucoup).
> très à jour
Fedora est assurément la distribution la plus à jour.
> avec beaucoup de paquets binaires
Fedora Core + Fedora Extras (qui ne contiennent que du libre) : 5700 paquets binaires, 3300 paquets sources.
> fonctionner "out of the box" sans pour autant m'imposer certaines choses
Globalement ça le fait pour Fedora. Bon compromis "out of the box" et personnalisation.
> avoir un système d'init plus moderne que les horribles rc.d SystemV
Fedora a toujours l'"horrible rc.d". Il y a un projet en cours mais ne semble pas très actif ou dans les priorités de Fedora : http://fedoraproject.org/wiki/FCNewInit
> l'installation avec LVM2
Depuis TRÈS longtemps (FC1 ?).
> et une partition chiffrée
OK mais post-installation. Actuellement ne marche pas avec la partition racine.
Dans le cahier des charges "non écrit" de Fedora, Fedora *doit* marcher avec un noyau vanilla (évidement des fonctionnalités sont perdues). J'ai un noyau adapté à ma configuration et ça marche nickel.
Evidement tu peux récupérer les sources Linux sur http://www.kernel.org/ et suivre la procédure classique. La procédure donnée dans la release note est pour utiliser les sources de Fedora.
> FC4 était instable et lourde
Lourde, c'est possible. Par défaut Fedora installe plein de choses. Ne pas oublier que Fedora est la base de RHEL qui est dédié entreprise (donc nfs, portmap, etc).
Il faut prendre le temps de virer les paquets qu'on utilise pas ou de désactivé les services qu'on utilise pas (avec system-config-services par exemple qui s'occupe des liens dans /etc/rc.d et des services de xinetd). Ici j'ai 590 paquets d'installé (autour de 900 lors de l'installation).
Ces changements rapides et les incompatibilités, parfois très importantes, qui en découlent ne facilitent pas la tâche des distributeurs.
[...]
Tant qu'une nouvelle branche de Linux ne sera pas ouverte, il sera difficile ou éphémère, pour une petite équipe, de distribuer un système stable, basé sur un Linux 2.6.
> t'façon on s'en fout de lui il est tout seul
Apprend à lire s'il te plait.
Je n'ai pas dit que je m'en fout de Slack. Mais les développeurs ont des priorités, doivent faire des choix pour contenter un maximum de personne et le chois qui a été fait n'est pas en faveur de Slack et de son mainteneur. C'est un fait. Point barre. Les difficultés des petites structures a dû être entendu. Mais que veux tu, le gros des développeurs viennent de grosse structure. Quand Jérôme Pinot le dit, ça ne te dérange pas, quand c'est moi tu en fais tout un fromage.
> on fait pas comme ça l'arrange, parce qu'il a pas son mot à dire
Il a son mot à dire. Arrêtes de dire des conneries.
> il est tout seul
Oui, il est tout seul. Malheureusement pour lui, les autres sont beaucoup plus nombreux. C'est un *fait* !
> Ce qui est à la fois débile, méprisant et hors-sujet.
Ce n'est pas débile, c'est un *fait*.
Ce n'est pas méprisant, c'est un *fait*.
Ce n'est pas hors-sujet, ça répond au commentaire de Jérôme Pinot.
Ecoutes bien, j'ai beaucoup de respect pour Slack et surtout pour son mainteneur qui réalise un travail ENORME. C'est un personnage "historique" de Linux et c'est grace à Slackware (distribution knoppix97 je crois) que j'ai découvert Linux.
Je comprend parfaitement que les gens apprécient Slackware. Une distribution qui ne casse pas tout du jour au lendemain. J'utilise Fedora, et parfois ça me "fatigue" de devoir mettre à jour mes connaissances pour utiliser pleinement ma distribution.
Slackware est indéniablement une distribution qui a sa place dans le paysage Linux. Mais les temps sont dures pour les petites structures et donc pour Slackware (Notes bien que je ne suis pas le seul à le dire). Je n'ai jamais dit que le mainteneur de Slackware était "naze" ou autre.
On dirait bien. Les mises à jours de FC4 sont plus recentes que FC5 (sans mise à jour).
Il te reste la voie "officielle". Graver les CD et faire une mise à jour.
Avant n'oublies pas de restaurer la version précédente de yum (rpm -Uvh --oldpackage yum.... ; yum clean all)
Il faut, comme toujours, replacer les choses dans leur contexte.
AIGLX/Compiz (et l'extension metacity en cours de développement) c'est du beta et plus probablement de l'alpha/technology preview comme logiciel. Ce n'est pas à mettre entre toute les mains.
Fedora, le mainteneur d'AIGLX, aura compiz désactivé par défaut pour FC6 (AIGLX et Xcompose était activé par défaut mais non utilisé). Et Fedora n'est pas convaincu d'avoir compiz (ou metacity utilisant AIGLX) activé par défaut pour FC7.
Les choses sont claires, il y a encore au minimum 6 bons mois de boulot d'après les développeurs.
Mon commentaire précédent avec un score de -5 alors que je dis simple ce qui se fait actuellement et ce qui fait consensus dans la majorité des développeurs à de quoi me prier de rire et démontre que Slack est sur une autre planète.
> Error: Missing Dependency: /lib/modules/2.6.17-1.2157_FC5 is needed by package dlm-kernel
Donc tu n'as pas mis à jour le noyau ?
N'oublies pas de le mettre à jour. Mais attends de lire la suite avant de le faire.
J'ai tenter de comprendre le problème, et je crois avoir trouvé une bonne voie.
Fedora supporte la mise à jours de FC(n) à FC(n+1) final, et non final+update.
Lorsque tu as mis à jour le paquet fedora-release, le dépôt des updates est activité. Donc un "yum update" ne fait pas FC(n) à FC(n+1) mais FC(n) à FC(n+1)+updates.
Par exemple pour ces messages d'erreur :
> Error: Missing Dependency: howl = 0.9.8 is needed by package howl-libs
> Error: Package howl-libs needs howl = 0.9.8, this is not available.
J'ai fait un diff dans les obsoletes entre FC5 et FC5+updates. J'y ai entre autre :
< avahi howl
C'est-à-dire que le avahi dans updates (celui retenu par yum puisque c'est la dernière version) ne met pas howl en obsolete alors qu'il le devrait puisque FC5 ne fournit pas howl mais avahi en remplaçant.
De même j'ai fait un diff entre les provides de avahi-0.6.9-3.x86_64.rpm (FC5) et avahi-0.6.10-1.FC5.x86_64.rpm (FC5+update). Entre autre, le paquet FC5+update n'a pas "provide: libhowl.so.0".
Donc pour une mise à jour de FC4 à FC5+update, ça ne peut pas marcher.
Ce n'est en aucun cas un bug de Yum. C'est un problème de packaging. Cette problématique ne semble pas prit en compte par les développeurs de Fedora actuellement.
> Tout ça en même temps, sans Xrun et out-of-the-box !
Bizarre. Depuis Linux 2.6, j'ai aucun problème Xrun (sauf cas exceptionnel comme lorsque je tape dans le swap avec "férocité"). Pourtant je n'ai pas de jack et j'ai une carte son "à la con" (une ens1371).
Moi j'ai rien contre /media. Il n'y a que les fs amovibles pour utilisateur dedans. Le therme média est bien choisi.
> En fouillant les mailing-lists, tu peux trouver de nombreuses personnes qui n'aiment pas ce /media rajouté récemment (2003).
Des grincheux on en trouve partout. Il faut mettre /media dans son contexte et par rapport à un utilisateur moyen (je ne parle pas du geek). Normalement /media tu l'ignores. Il n'y a pas à taper de "mount /media/etc", il ne doit pas y avoir de "/media" dans /etc/fstab, et les interfaces graphique ne doivent pas présenter /media mais simplement les périphériques amovibles (gentillement posé sur le bureau (~/Desktop) pour que l'utilisateur ne fouille pas dans /media ou on ne sait où)
> Mais à priori, les archi 64bits savent aussi utiliser du 32 bits, non ?
Oui et à priori yum gère ça (c'est le seul à le faire :-)).
A vue de nez, je ne vois pas de problème dans ta liste.
Que donne "yum upgrade" (ou la mise à jour de yum vers la version de FC5 en premier) ?
Car quand je vois tes messages d'erreus, j'envisage deux causes :
- les tags "obsolete" ne sont respectés
- tu as activé les dépôts yum [updates] mais pas [core]
Désolé, mon exemple n'était pas terrible. Ma clée usb tombant toujours sur le même fichier spécial, j'ai tendance à utiliser le fichier spécial. On peut aussi utiliser le label du périphérique.
Exemple : [me@here ~]$ gnome-mount -t -p usb_copy
gnome-mount 0.5
Resolved pseudonym "usb_copy" -> /dev/sda
Mounted /dev/sda at "/media/usb_copy"
Devices mounted through an automatic desktop mechanism must be unmounted with the same mechanism (the "remove safely" action offered by the file/device manager applications). Such devices cannot currently be unmounted from the command line, except by the super-user.
Comique. Sous FC5 ce qui est (dé)monté par gnome-volume-manager peut-être (dé)monté avec la ligne de commande. Idem pour FC6 (qui sort la semaine prochaine).
Au-lieu d'utiliser "yum update" essais avec "yum upgrade".
Il me semble que "yum upgrade" allait devenir obsolete.
Selon la man de yum :
upgrade
Is the same as the update command with the --obsoletes flag set. See update for more details.
Si ça ne marche pas, commence par mettre à jour yum : "yum update "yum*"
Puis nettoye le cache de yum : "yum clean all"
Puis fait la mise à jour : "yum upgrade" ou "yum update" (commence par "yum update").
Ooops, je n'ai pas fait attention que tu as kernel et kernel-smp.
Ceci est un peu anormal, tu ne devrais avoir que l'un des deux. Mais c'est sans gravité.
Donc, fait un "yum install kernel-smp kernel".
Normalement les kernel (sans -smp) peuvent marcher sur des machines smp.
En première lecture, je le comprend comme toi.
Mais en y réfléchissant un peu, ça n'a pas de sens.
Pour moi il faut bien installer le noyau FC5 en premier, puis virer le noyau FC4, puis installer fedora-release, puis faire un "yum update".
On peut installer fedore-release pour éviter d'installer manuellement les /etc/yum.repo.d/* .
Peux-tu faire :
* rpm -Uhv http://download.fedora.redhat.com/pub/fedora/linux/core/5/i3(...)
* yum install kernel-smp ### !!! Tu as un smp
* yum remove kernel-smp-2.6.17-1.2142_FC4 kernel-2.6.17-1.2142_FC4 kernel-doc-2.6.17-1.2142_FC4 ### !!! ATTENTION ici il faut bien spécifier la version
* yum update
* /sbin/fixfiles relabel
A la fin de toutes les commandes ajoutes "2>&1 | tee -a output".
Par exemple : "yum update 2>&1 | tee -a output"
Ça donnera un log.
T'as encore un ancien noyau.
Au lieu de faire "yum remove kernel-2.6.14", fais :
* yum remove kernel-smp-2.6.17-1.2142_FC4 kernel-2.6.17-1.2142_FC4 kernel-doc-2.6.17-1.2142_FC4
De plus tu n'as pas appliqué la procédure. Il faut faire un "yum install kernel" avant de faire "yum remove kernel...." et aussi avant de faire "yum update".
Si tu avais respecté la procédure, tu aurais un kernel-smp-...._FC5.
[^] # Re: urmi
Posté par clearstream . En réponse au journal Passage de Debian a Mandriva 2007. Évalué à 0.
> rechercher selon divers filtres / installer-desintaller
Yum search. Combiné avec --enablerepo et --disablerepo, ça le fait.
Pour un recherche fine des paquets installé, rpm avec les options --queryformat --whatrequires --whatprovides est ce qu'il y a de mieux.
Avec Yum, il y a aussi le programme repoquery. Il n'interroge pas la base rpm locale (/var/lib/rpm). On retourve toute la puissance de "rpm --queryformat" + --whatrequires --whatobsoletes --whatconflicts --resolve.
> filtres avancés (exclusion de certains noms ou parties de noms par exemple)
Yum --exclude. C'est aussi configurable dans /etc/yum.conf ou via des fichiers dans /etc/yum.repo.d/
Il y a aussi les plugin yum-protectbase, plugin yum-versionlock, yum-allowdowngrade, yum-kernel-module et yum-fedorakmod.
> gestion avancée des dépendances
Heureusement. Idem pour tout le monde.
> gestion des signatures
C'est-à-dire ?
Yum vérifie si le paquet est signé, il peut aussi importer une signature (via ftp, http, etc).
> gestion des débits, splitter en transactions, splitter par poids,
Yum n'a pas.
Il y a yum-fastestmirror.
> garder/enlever du cache (et gestion avancé de celui-ci)
Yum n'a pas. Mais le cache est si petit (ici 100 Mo pour 5700 paquets info de liste de fichier comprise (alors que c'est peut utilisé)).
> passer par un proxy, utiliser ssh curl et wget
Yum a.
> synchronisation...
reposync.
> gestion de liste d' exclusion précise
???
Consédirons que Yum n'a pas.
> reconstructions
Yum n'a pas.
Mais c'est tellement con à faire avec rpm : rpm --rebuild [url]
Il y a aussi yum-builddep pour installé les *-devel nécessaires.
> gestion des architectures
Yum a. +gestion biarch.
> ne pas exécuter les scriptlets
Il y a le plugin yum-tsflags. Mais franchement, vu que yum/urpmi peut installé plusieurs paquets, c'est une mauvaise idée. Rpm le fait "--noscript --notrigger".
> installation en parallèle sur plusieurs (dizaine(s) ...) de postes.
Un serveur urpmi ?
C'est assez con à faire avec yum-updatesd (indique s'il y a des mises à jours via syslog, mail et dbus).
Peut aussi mettre à jours automatique et downloader.
Exemple d'un fichier de configuration :
Après pour l'installation automatique d'un nouveau paquet, il suffit d'installé un paquet "meta", voire un nouveau fedora-release avec un epoc supérieur à celui fournit par défaut pour être tranquille. Ainsi toute les bécanes qui point sur le dépôt on le paquet. S'il faut ajouter un programme, on ajoute un Require au paquet. S'il faut virer un programme, on ajoute un tag "obsolete".
Pas compliqué à faire pour 1, 10 ou 200 000 machines.
> gestion d' un parc d' ordinateurs
Ça m'étonnerait que urpmi fasse ça.
> gérer complètement les chroot depuis l' environnement courant.
???
yum --installroot. NB, ça aussi évidement fournit par rpm.
> utiliser un environnement différent
???
Ben avec setarch, -c [config file] et --installroot, je ne vois pas ce qu'on peut vouloir de plus.
Sous Fedora yum est utilisé pour installer des machines virtuelles (Xen).
> et encore quelques autres!
Idem pour yum. Tiens, il y a repoview :
http://fr2.rpmfind.net/linux/fedora/core/5/x86_64/os/repodat(...)
Et un flux rss :
http://fr2.rpmfind.net/linux/fedora/extras/5/i386/repodata/l(...)
Sympathique, non ?
Je ne veux pas dénigrer urpmi.
L'avantage de yum, c'est qu'il est simple. S'il faut faire des trucs compliqués, il y a d'autres programmes.
Pour Yum et un utilisateur classique, il faut une page man. Pour urpmi, il faut un site dédié à la maitrise de urpmi.
Pour ton info, compares aussi avec smart.
# Voir l'exemple de Red Hat & Novell
Posté par clearstream . En réponse au journal Mandriva veut raccourcir le cycle de sortie à 6 ou 4 mois. Évalué à 4.
Le cycle de 6 mois, permet aussi de se synchroniser avec Gnome notamment. Beaucoup de projets ont maintenant un cycle de 6 mois avec un roadmap.
Au-delà des contributions extérieures, les utilisateurs de la version communautaire/gratuite seront des futurs utilisateurs de la version payante (pour Mandriva, la corporate server).
Je pense que Mandriva c'est rendu compte qu'avec un cycle long (1 ans pour la 2007), il y a peu de participation (au moins pour les 6 premiers mois du cycle).
Ajoutons la popularité d'Ubuntu grandissante par rapport à Mandriva alors qu'elle sort tous les 6 mois, on en déduit que le soit-disant avantage de sortir tout les ans n'en est pas un en fin de compte (compte aussi dans le sens "monnaie sonnante et trébuchante"). Notons que Mandriva c'est un peu cassé la gueule en terme de popularité et le passage à un cycle de 1 an ne semble en rien avoir atténué ce cassage de gueule.
Je pense que l'étape suivante pour Mandriva, sera de suivre encore un peu plus Fedora => ne pas proposer de boîte (ça coûte cher à mettre oeuvre, le processus est complexe).
Ce que j'imagine à moyen terme :
- une distribution gratuite (download uniquement donc)
- voire une distribution "boite" avec un packaging minimum (pas de doc papier, un truc à 10 ¤ maxi).
- Mandriva club.
- Mandriva corporate serveur.
A l'instar de Fedora, Mandriva va avoir un support en temps très limité.
Autre "bénéfice" pour Mandriva, mieux distinguer la Mandriva "classique" de la Mandriva Corporate Server et donc attirer des gens vers la Corporate Server qui peut-être jusque là se satisfesaient de la "classique".
Dernier truc qui moi m'a "chiffonné", c'est l'aspect "déjà vieux" de la Corporate Server 4. Elle est sortie il y a quelques semaines mais est basée sur une Mandriva 2006 (1 an d'age). Donc, Mandriva avec le couple "classique"/CS va sûrement faire comme le couple Fedora/RHEL.
Comme pour Fedora, on pourra dire que la "classique" est la version de test/alpha de la CS. Un troll est mort.
Si c'est comme je l'image, Mandriva est sûr la bonne voie. Il lui reste a communiquer avec transparence pour qu'on ne nage pas dans un grand flou.
[^] # Re: Gestionnaire de packages
Posté par clearstream . En réponse au journal Passage de Debian a Mandriva 2007. Évalué à 6.
C'est du libre, donc inutile d'aligner du pognon pour l'avoir.
> c'etait prometeur...
C'est toujours un excellent gestionnaire de paquet.
> que urpmi etait pas aussi bien
urpmi j'ai toujours trouvé ça naze. C'est compliqué, il y a 50 commandes, etc...
OK, j'ai très très peu utilisé urpmi, mais c'est l'impression que ça donne quand on l'utilise (même peu) et quand on lit linuxfr.
> je me demande si smart est toujours maintenu
Oui : http://labix.org/smart/
Dernière version sortie le 15/06/2006 : http://lists.labix.org/pipermail/smart-labix.org/2006-June/0(...)
> bref quel est la politique de mandriva a ce sujet ?
Je ne parlerai pas au nom de mandriva. Mais chez Fedora la question d'utiliser Smart a été posé car Smart est un très bon gestionnaire de paquet "dans son genre". Mais Smart pose plusieur problème à Fedora. Sa politique de résolutions des dépendances ne plait pas à Fedora (Fedora a de bonnes raisons de le penser). En effet, smart peut downgrader un paquet pour satisfaire des dépendances. Au moins pour des raisons de sécurité, Fedora se le refuse.
L'autre problème, et il est lié au précédent, est que smart ne passe pas rpm-lib pour voir si les dépendances sont satisfaites.
Smart ne supporte pas les groups de Fedora (fichier comps.xml ; à ne pas confondre avec les groupes de rpm).
Smart ne permet pas de mixer i386 et x86_64.
En conclusion, si on est d'accord avec le choix pour la résolution des dépendance fait par Smart, Smart est un excellent gestionnaire de paquet (et 50 fois plus simple que urpmi) et il mérite d'être plus populaire.
Avis perso.
[^] # Re: LVM2
Posté par clearstream . En réponse au message À la recherche de la distribution perdue.. Évalué à 1.
FC6 a ajouté le cryptage. Malheureusement pas encore pour la partition racine. Je n'utilise pas le cryptage (pas pour un FS complet) dont je ne peut en dire beaucoup plus. Mais il y a un support pour monter des partitions cryptées facilement (/etc/crypttab), c'est supporté par initcript, c'est supporté par hal, gnome-volume-manager, gnome-mount, etc, mais pas encore par l'installeur (anaconda).
Voir le release note et cherche "crypt" :
http://fr2.rpmfind.net/linux/fedora/core/development/i386/os(...)
Du journal :
> à une époque plus lointaine GCJ et SELinux
Fedora supporte SeLinux depuis FC3 et c'est activé par défaut.
Fedora propose GCJ (java-gcj-compat, tomcat, etc) depuis assez longtemps et ça ne fait que s'améliorer. C'est aujourd'hui la référence libre du java. Aujourd'hui, bien que ça ne soit pas parfait, Le "java" de Fedora fait tourner Azureus, rssowl, eclipse, etc...
Il y a aussi un plugin java pour firefox (voir la release note).
> Idéalement, la nouvelle distribution devrait être tout à fait libre
C'est le cas de Fedora.
> stable
Stable ? Fedora est *fiable*. Par contre elle n'est pas stable (elle change beaucoup).
> très à jour
Fedora est assurément la distribution la plus à jour.
> avec beaucoup de paquets binaires
Fedora Core + Fedora Extras (qui ne contiennent que du libre) : 5700 paquets binaires, 3300 paquets sources.
> fonctionner "out of the box" sans pour autant m'imposer certaines choses
Globalement ça le fait pour Fedora. Bon compromis "out of the box" et personnalisation.
> avoir un système d'init plus moderne que les horribles rc.d SystemV
Fedora a toujours l'"horrible rc.d". Il y a un projet en cours mais ne semble pas très actif ou dans les priorités de Fedora :
http://fedoraproject.org/wiki/FCNewInit
> l'installation avec LVM2
Depuis TRÈS longtemps (FC1 ?).
> et une partition chiffrée
OK mais post-installation. Actuellement ne marche pas avec la partition racine.
> Facile de compiler son propre kernel ?
Chercher "Preparing for Kernel Development" dans http://fr2.rpmfind.net/linux/fedora/core/development/i386/os(...)
Pour ma part, je me refait un paquet rpm (en me basant sur celui de Fedora) que j'installe après de façon classique.
Dans le cahier des charges "non écrit" de Fedora, Fedora *doit* marcher avec un noyau vanilla (évidement des fonctionnalités sont perdues). J'ai un noyau adapté à ma configuration et ça marche nickel.
Evidement tu peux récupérer les sources Linux sur http://www.kernel.org/ et suivre la procédure classique. La procédure donnée dans la release note est pour utiliser les sources de Fedora.
> FC4 était instable et lourde
Lourde, c'est possible. Par défaut Fedora installe plein de choses. Ne pas oublier que Fedora est la base de RHEL qui est dédié entreprise (donc nfs, portmap, etc).
Il faut prendre le temps de virer les paquets qu'on utilise pas ou de désactivé les services qu'on utilise pas (avec system-config-services par exemple qui s'occupe des liens dans /etc/rc.d et des services de xinetd). Ici j'ai 590 paquets d'installé (autour de 900 lors de l'installation).
> dirigisme ?
Absolument pas.
[^] # Re: Slackware, Debian edition
Posté par clearstream . En réponse à la dépêche Linux Slackware 11.0 est disponible. Évalué à -1.
Je n'ai pas dit qu'il s'était plaint.
> Toi tu dis "wééé, c'est dur, mais c'est normal,
Je ne suis pas le seul. Commentaire de http://linuxfr.org/comments/760880,1.html
> t'façon on s'en fout de lui il est tout seul
Apprend à lire s'il te plait.
Je n'ai pas dit que je m'en fout de Slack. Mais les développeurs ont des priorités, doivent faire des choix pour contenter un maximum de personne et le chois qui a été fait n'est pas en faveur de Slack et de son mainteneur. C'est un fait. Point barre. Les difficultés des petites structures a dû être entendu. Mais que veux tu, le gros des développeurs viennent de grosse structure. Quand Jérôme Pinot le dit, ça ne te dérange pas, quand c'est moi tu en fais tout un fromage.
> on fait pas comme ça l'arrange, parce qu'il a pas son mot à dire
Il a son mot à dire. Arrêtes de dire des conneries.
> il est tout seul
Oui, il est tout seul. Malheureusement pour lui, les autres sont beaucoup plus nombreux. C'est un *fait* !
> Ce qui est à la fois débile, méprisant et hors-sujet.
Ce n'est pas débile, c'est un *fait*.
Ce n'est pas méprisant, c'est un *fait*.
Ce n'est pas hors-sujet, ça répond au commentaire de Jérôme Pinot.
Ecoutes bien, j'ai beaucoup de respect pour Slack et surtout pour son mainteneur qui réalise un travail ENORME. C'est un personnage "historique" de Linux et c'est grace à Slackware (distribution knoppix97 je crois) que j'ai découvert Linux.
Je comprend parfaitement que les gens apprécient Slackware. Une distribution qui ne casse pas tout du jour au lendemain. J'utilise Fedora, et parfois ça me "fatigue" de devoir mettre à jour mes connaissances pour utiliser pleinement ma distribution.
Slackware est indéniablement une distribution qui a sa place dans le paysage Linux. Mais les temps sont dures pour les petites structures et donc pour Slackware (Notes bien que je ne suis pas le seul à le dire). Je n'ai jamais dit que le mainteneur de Slackware était "naze" ou autre.
S'il te plait, apprend à lire.
[^] # Re: Slackware, Debian edition
Posté par clearstream . En réponse à la dépêche Linux Slackware 11.0 est disponible. Évalué à -1.
Très bien. Il n'y a pas de problème et tout va bien.
Alors pourquoi ce dernier commentaire à un score de 10 ?
http://linuxfr.org/comments/760880,1.html
[^] # Re: Re:
Posté par clearstream . En réponse au message Mise à jour FC4 -> FC5. Évalué à 0.
On dirait bien. Les mises à jours de FC4 sont plus recentes que FC5 (sans mise à jour).
Il te reste la voie "officielle". Graver les CD et faire une mise à jour.
Avant n'oublies pas de restaurer la version précédente de yum (rpm -Uvh --oldpackage yum.... ; yum clean all)
# Déçu ?!?!
Posté par clearstream . En réponse au journal compiz et aiglx dans ma sid box !. Évalué à 1.
AIGLX/Compiz (et l'extension metacity en cours de développement) c'est du beta et plus probablement de l'alpha/technology preview comme logiciel. Ce n'est pas à mettre entre toute les mains.
Fedora, le mainteneur d'AIGLX, aura compiz désactivé par défaut pour FC6 (AIGLX et Xcompose était activé par défaut mais non utilisé). Et Fedora n'est pas convaincu d'avoir compiz (ou metacity utilisant AIGLX) activé par défaut pour FC7.
Les choses sont claires, il y a encore au minimum 6 bons mois de boulot d'après les développeurs.
[^] # Re: Slackware, Debian edition
Posté par clearstream . En réponse à la dépêche Linux Slackware 11.0 est disponible. Évalué à -6.
[^] # Re: Re:
Posté par clearstream . En réponse au message Mise à jour FC4 -> FC5. Évalué à 1.
Désolé, il y a erreur puisqu'il n'y a pas de kernel-smp dans FC5. Il faut :
* yum install --disablerepo=updates kernel
Pour info, si tu as besoin de remettre l'ancien noyau (celui pour FC4) il faut faire :
* rpm -ivh --oldpackage kernel-2.6.17-1.2142_FC4.x86_64.rpm
[^] # Re: Re:
Posté par clearstream . En réponse au message Mise à jour FC4 -> FC5. Évalué à 1.
Donc tu n'as pas mis à jour le noyau ?
N'oublies pas de le mettre à jour. Mais attends de lire la suite avant de le faire.
J'ai tenter de comprendre le problème, et je crois avoir trouvé une bonne voie.
Fedora supporte la mise à jours de FC(n) à FC(n+1) final, et non final+update.
Lorsque tu as mis à jour le paquet fedora-release, le dépôt des updates est activité. Donc un "yum update" ne fait pas FC(n) à FC(n+1) mais FC(n) à FC(n+1)+updates.
Par exemple pour ces messages d'erreur :
> Error: Missing Dependency: howl = 0.9.8 is needed by package howl-libs
> Error: Package howl-libs needs howl = 0.9.8, this is not available.
J'ai fait un diff dans les obsoletes entre FC5 et FC5+updates. J'y ai entre autre : C'est-à-dire que le avahi dans updates (celui retenu par yum puisque c'est la dernière version) ne met pas howl en obsolete alors qu'il le devrait puisque FC5 ne fournit pas howl mais avahi en remplaçant.
De même j'ai fait un diff entre les provides de avahi-0.6.9-3.x86_64.rpm (FC5) et avahi-0.6.10-1.FC5.x86_64.rpm (FC5+update). Entre autre, le paquet FC5+update n'a pas "provide: libhowl.so.0".
Donc pour une mise à jour de FC4 à FC5+update, ça ne peut pas marcher.
Ce n'est en aucun cas un bug de Yum. C'est un problème de packaging. Cette problématique ne semble pas prit en compte par les développeurs de Fedora actuellement.
Nouvelle procédure :
* rpm -Uhv http://download.fedora.redhat.com/pub/fedora/linux/core/5/i3(...) ### normalement déjà fait
* yum install --disablerepo=updates kernel-smp kernel
* yum remove kernel-smp-2.6.17-1.2142_FC4 kernel-2.6.17-1.2142_FC4 ### !!! ATTENTION ici il faut bien spécifier la version
* yum update --disablerepo=updates
* yum update
* /sbin/fixfiles relabel
J'espère que ça va marcher.
[^] # Re: Le son dans la 2007
Posté par clearstream . En réponse à la dépêche Mandriva Linux 2007 disponible pour tous. Évalué à 0.
Bizarre. Depuis Linux 2.6, j'ai aucun problème Xrun (sauf cas exceptionnel comme lorsque je tape dans le swap avec "férocité"). Pourtant je n'ai pas de jack et j'ai une carte son "à la con" (une ens1371).
[^] # Re: Il faudrait ajouter les liens vers les releases notes et les errata
Posté par clearstream . En réponse à la dépêche Mandriva Linux 2007 disponible pour tous. Évalué à 1.
[^] # Re: Il faudrait ajouter les liens vers les releases notes et les errata
Posté par clearstream . En réponse à la dépêche Mandriva Linux 2007 disponible pour tous. Évalué à 1.
Merci pour la précision.
Moi j'ai rien contre /media. Il n'y a que les fs amovibles pour utilisateur dedans. Le therme média est bien choisi.
> En fouillant les mailing-lists, tu peux trouver de nombreuses personnes qui n'aiment pas ce /media rajouté récemment (2003).
Des grincheux on en trouve partout. Il faut mettre /media dans son contexte et par rapport à un utilisateur moyen (je ne parle pas du geek). Normalement /media tu l'ignores. Il n'y a pas à taper de "mount /media/etc", il ne doit pas y avoir de "/media" dans /etc/fstab, et les interfaces graphique ne doivent pas présenter /media mais simplement les périphériques amovibles (gentillement posé sur le bureau (~/Desktop) pour que l'utilisateur ne fouille pas dans /media ou on ne sait où)
[^] # Re: Re:
Posté par clearstream . En réponse au message Mise à jour FC4 -> FC5. Évalué à 1.
Oui et à priori yum gère ça (c'est le seul à le faire :-)).
A vue de nez, je ne vois pas de problème dans ta liste.
Que donne "yum upgrade" (ou la mise à jour de yum vers la version de FC5 en premier) ?
Car quand je vois tes messages d'erreus, j'envisage deux causes :
- les tags "obsolete" ne sont respectés
- tu as activé les dépôts yum [updates] mais pas [core]
[^] # Re: Il faudrait ajouter les liens vers les releases notes et les errata
Posté par clearstream . En réponse à la dépêche Mandriva Linux 2007 disponible pour tous. Évalué à 1.
Je dois reconnaitre que j'ai mal lu.
Enfin, c'est un peu plus compliqué. La version française en fausse : http://qa.mandriva.com/twiki/bin/view/Main/MandrivaLinux2007(...)
La version anglaise est correcte.
[^] # Re: Il faudrait ajouter les liens vers les releases notes et les errata
Posté par clearstream . En réponse à la dépêche Mandriva Linux 2007 disponible pour tous. Évalué à 0.
Exemple :
[me@here ~]$ gnome-mount -t -p usb_copy
gnome-mount 0.5
Resolved pseudonym "usb_copy" -> /dev/sda
Mounted /dev/sda at "/media/usb_copy"
Il est plus intéligent d'utiliser le label.
[^] # Re: Il faudrait ajouter les liens vers les releases notes et les errata
Posté par clearstream . En réponse à la dépêche Mandriva Linux 2007 disponible pour tous. Évalué à -1.
[^] # Re: Il faudrait ajouter les liens vers les releases notes et les errata
Posté par clearstream . En réponse à la dépêche Mandriva Linux 2007 disponible pour tous. Évalué à -2.
Comique. Sous FC5 ce qui est (dé)monté par gnome-volume-manager peut-être (dé)monté avec la ligne de commande. Idem pour FC6 (qui sort la semaine prochaine).
Exemple sous FC6 (mode verbeux) :
[me@head ~]$ gnome-mount -v -t -d /dev/sda
gnome-mount 0.5
** (gnome-mount:4452): DEBUG: Mounting /org/freedesktop/Hal/devices/volume_uuid_4438_F36E
** (gnome-mount:4452): DEBUG: read default option 'shortname=winnt' from gconf strlist key /system/storage/default_options/vfat/mount_options
** (gnome-mount:4452): DEBUG: read default option 'uid=' from gconf strlist key /system/storage/default_options/vfat/mount_options
** (gnome-mount:4452): DEBUG: Mounting /org/freedesktop/Hal/devices/volume_uuid_4438_F36E with mount_point='usb_copy', fstype='', num_options=2
** (gnome-mount:4452): DEBUG: option='shortname=winnt'
** (gnome-mount:4452): DEBUG: option='uid=500'
Mounted /dev/sda at "/media/usb_copy"
[me@here ~]$ gnome-umount -v -t -d /dev/sda
gnome-mount 0.5
** (gnome-umount:4485): DEBUG: Unmounting /org/freedesktop/Hal/devices/volume_uuid_4438_F36E
** (gnome-umount:4485): DEBUG: Setting up 750ms timer for Flushing Cache dialog
** (gnome-umount:4485): DEBUG: in unmount_done : user_data = 0x0
Unmounted /dev/sda
[me@here ~]$
Marche aussi en mode graphique.
[^] # Re: Re:
Posté par clearstream . En réponse au message Mise à jour FC4 -> FC5. Évalué à 1.
Vérifies avec : "rpm -q --queryformat="%{ARCH} %{NAME}\n" -a | grep i386"
[^] # Re: Re:
Posté par clearstream . En réponse au message Mise à jour FC4 -> FC5. Évalué à 1.
Il me semble que "yum upgrade" allait devenir obsolete.
Selon la man de yum :
Si ça ne marche pas, commence par mettre à jour yum : "yum update "yum*"
Puis nettoye le cache de yum : "yum clean all"
Puis fait la mise à jour : "yum upgrade" ou "yum update" (commence par "yum update").
[^] # Re: Re:
Posté par clearstream . En réponse au message Mise à jour FC4 -> FC5. Évalué à 1.
Ooops, je n'ai pas fait attention que tu as kernel et kernel-smp.
Ceci est un peu anormal, tu ne devrais avoir que l'un des deux. Mais c'est sans gravité.
Donc, fait un "yum install kernel-smp kernel".
Normalement les kernel (sans -smp) peuvent marcher sur des machines smp.
[^] # Re: Re:
Posté par clearstream . En réponse au message Mise à jour FC4 -> FC5. Évalué à 1.
Mais en y réfléchissant un peu, ça n'a pas de sens.
Pour moi il faut bien installer le noyau FC5 en premier, puis virer le noyau FC4, puis installer fedora-release, puis faire un "yum update".
On peut installer fedore-release pour éviter d'installer manuellement les /etc/yum.repo.d/* .
Peux-tu faire :
* rpm -Uhv http://download.fedora.redhat.com/pub/fedora/linux/core/5/i3(...)
* yum install kernel-smp ### !!! Tu as un smp
* yum remove kernel-smp-2.6.17-1.2142_FC4 kernel-2.6.17-1.2142_FC4 kernel-doc-2.6.17-1.2142_FC4 ### !!! ATTENTION ici il faut bien spécifier la version
* yum update
* /sbin/fixfiles relabel
A la fin de toutes les commandes ajoutes "2>&1 | tee -a output".
Par exemple : "yum update 2>&1 | tee -a output"
Ça donnera un log.
[^] # Re: Et Slack ?
Posté par clearstream . En réponse au journal OpenSuse et ReiserFS. Évalué à 1.
Si t'attends une correction "officielle", ça peut prendre du temps (quelques semaines).
[^] # Re: Re:
Posté par clearstream . En réponse au message Mise à jour FC4 -> FC5. Évalué à 1.
T'as encore un ancien noyau.
Au lieu de faire "yum remove kernel-2.6.14", fais :
* yum remove kernel-smp-2.6.17-1.2142_FC4 kernel-2.6.17-1.2142_FC4 kernel-doc-2.6.17-1.2142_FC4
De plus tu n'as pas appliqué la procédure. Il faut faire un "yum install kernel" avant de faire "yum remove kernel...." et aussi avant de faire "yum update".
Si tu avais respecté la procédure, tu aurais un kernel-smp-...._FC5.