Ce petit retour d'utilisation de la dernière Fedora m'a quelque peu amusé.
http://www.placenet.org/benoit/index.php/post/2008/04/21/Que(...)
PS: Oui, ceci est un troll
http://www.placenet.org/benoit/index.php/post/2008/04/21/Que(...)
PS: Oui, ceci est un troll
> Lire le journal (105 commentaires, moyenne: 3,5).
Vous avez demandé le commentaire #924789.
Run by 
Cette page a été générée par Templeet en 0.1497s (dont 0.0107 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Yum remove considered harmful
> Ce sont des gros méta-paquets (...) Impossible de savoir ce qu'il y a dedans
C'est un "défaut" (c'est plutôt un choix de conception qu'un défaut) propre à Pirut (qui est gentillement poussé vers la porte de sortie en tant qu'application standalone par PackageKit). Avec Yumex, tu peux voir le contenu des groupes (et les modifier).
Pour l'utilisateur de base, il n'a pas besoin de savoir ce que contient le groupe, c'est le rôle du distributeur de faire des choix cohérents, en ce sens, Pirut fait son boulot, les utilisateurs avancés peuvent passer à Pirut. C'est un choix du distributeur de fournir un outil simple conforme aux HIG de GNOME (si, si, Pirut est conforme)
> il n'y pas de gestion de dépendances entre les méta-paquets
Faux (voir juste en dessous). Au passage, ce ne sont pas des meta-paquets mais des groupes (une sorte de "suggestions") définis dans un fichier xml (comps.xml)
> Seulement les dépendances et RPM, même 10 ans après, ça ressemble toujours à de l'escroquerie.
L'escroquerie c'est de FUD-er sur RPM sans savoir de quoi, on parle. Ici, le problème n'est pas RPM (qui au passage, vaut bien dpkg), mais en l'occurence yum !
yum a un (très) gros problème dans la gestion des dépendances au moment de supprimer un paquet.
Pour faire simple, soit les paquets A et B qui ont une dépendance commune envers le paquet C, j'installe d'abord A (et donc logiquement C) puis B (C étant déjà installé). Si je supprime A, je m'attends à ce que yum conserve C, mais là yum a un comportement stupide. A et C ayant été installé ensemble, yum va supprimer A, puis C et logiquement B puisque C va être supprimé.
Pas étonnant qu'avec ce comportement de merde, on fout le boxon sur sa Fedora.
J'adore yum, il est puissant, rapide, extensible mais il a un gros défaut "yum remove", personnellement, je supprime les paquets directement via rpm (c'est plus rapide et moins risqué).
Il y a d'ailleurs eu un billet sur le planet fedoraproject à ce sujet, récemment.
> Vous pouvez aussi en déduire que personne n'utilise Fedora, en français du moins
Du pur troll -je suppose que c'est humoristique- , suffit d'aller sur fedora-fr.org pour voir que la communauté francophone est active. Par contre, on manque cruellement de traducteurs/relecteurs, donc si il y a des volontaires. ;-)
>J'ai flingué mon système en voulant juste supprimer "Sons et vidéos", "Graphismes", "Internet basé sur texte" (sic) et quelques trucs comme ça.
Si le billet est globalement de mauvaise foi rempli d'inexactitudes (après tout, on ne peut pas demander à un simple utilisateur d'avoir une connaissance approfondie de son système) , je rejoins l'auteur du billet sur ce point: ce comportement est INACCEPTABLE.
Certes, on recommande aux utilisateurs de toujours vérifier ce que yum supprime avant de valider mais ça reste une rustine.
[^]Re: Yum remove considered harmful
Pour faire simple, soit les paquets A et B qui ont une dépendance commune envers le paquet C, j'installe d'abord A (et donc logiquement C) puis B (C étant déjà installé). Si je supprime A, je m'attends à ce que yum conserve C, mais là yum a un comportement stupide. A et C ayant été installé ensemble, yum va supprimer A, puis C et logiquement B puisque C va être supprimé.
Pas étonnant qu'avec ce comportement de merde, on fout le boxon sur sa Fedora.
Pas étonnant surtout que tout le monde prétende qu'APT soit mieux foutu que yum. Ce genre de comportement sur une opération de base c'est quand même du grand n'importe quoi, surtout pour ce qui est censé être le principal outil de gestion de paquets d'une distrib...
[^]Re: Yum remove considered harmful
Faut pas oublier que c'est une explication simplifiée, ce n'est pas le cas général.
Dans 95% des cas, le problème est lié à la suppression d'un paquet de base, mais dans les 5% restants, c'est un problème de packaging (certains paquets gagneraient à être découpés plus finement) et un chouïa d'optimisation dans yum.
Au passage, yum est nettement plus jeune que dpkg, normal qu'il subsiste encore quelques cas particuliers.
[^]Re: Yum remove considered harmful
> c'est un problème de packaging
Ben tu le retrouveras dans PackageKit et apt et tous les autres.
[^]Re: Yum remove considered harmful
Ben tu le retrouveras dans PackageKit et apt et tous les autres.
Sauf que chez Debian on sait faire des paquets correctement...
[^]Re: Yum remove considered harmful
Super. Un bug (peut-être, car la dépendance n'est peut-être pas la pour rien) est découvert dans Fedora, et Debian fait le coq.
[^]Re: Yum remove considered harmful
Vu ton message plus bas sur liferea et libpurple qui dependent de NetworkManager, ca a l'air general, l'etat moisi des packages Fedora...
Ceci dit, je suis tres honore d'apprendre que ma parole represente toute l'organisation Debian...
[^]Re: Yum remove considered harmful
> Vu ton message plus bas sur liferea et libpurple qui dependent de NetworkManager, ca a l'air general, l'etat moisi des packages Fedora...
C'est con, mais ses dépendances sont obligatoires. Vire NetworkManager et liferea ne marche plus. L'absence de ses dépendance serait une erreur (et non le contraire).
[root@one share]# ldd /usr/bin/liferea-bin | grep libnmlibnm_glib.so.0 => /usr/lib64/libnm_glib.so.0 (0x00002aaaacb8a000)
libnm-util.so.0 => /usr/lib64/libnm-util.so.0 (0x00002aaaad413000)
> Ceci dit, je suis tres honore d'apprendre que ma parole represente toute l'organisation Debian...
Ben un dépendance (peut-être) superflux n'est pas représentatif de l'état des packages de Fedora.
Accuse moi de généraliser pour Debian. Mais tu généralise aussi avec Fedora. Balle au centre.
[^]Re: Yum remove considered harmful
C'est con, mais c'est pour ca que les packages Debian séparent les lib des programmes réels. Comme ca liferea dépend de libnm-glib0, et pas de network-manager. Vire NetworkManager, liferea marche toujours.
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: Yum remove considered harmful
Mais oui.
La liaison avec libnm-util.so.0 elle vient d'où à ton avis ? De rpm ?
Ben non, elle vient de ld.
> Debian séparent les lib des programmes réels.
Excellente idée. Fedora fait de même :
# # rpm -q --provides NetworkManager-gliblibnm_glib.so.0()(64bit)
libnm_glib_vpn.so.0()(64bit)
NetworkManager-glib = 1:0.7.0-0.6.7.svn3235.fc8
[^]Re: Yum remove considered harmful
> La liaison avec libnm-util.so.0 elle vient d'où à ton avis ? De rpm ?
Elle vient de ldd, qui liste toutes les dépendences directes et indirectes. En l'occurence liferea n'utilise aucun symbole directement de libnm-utils. Et meme si c'était le cas, cette lib est *aussi* un package séparé, on peut toujours virer NM.
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: Yum remove considered harmful
> En l'occurence liferea n'utilise aucun symbole directement de libnm-utils.
Liferea de F8 utilise libnm-utils. C'est un fait. Je ne sais pas pourquoi, mais c'est un fait. Ce n'est pas une invention de rpm ou du packager.
> Et meme si c'était le cas, cette lib est *aussi* un package séparé, on peut toujours virer NM.
Cool.
[^]Re: Yum remove considered harmful
> Liferea de F8 utilise libnm-utils. C'est un fait. Je ne sais pas pourquoi, mais c'est un fait. Ce n'est pas une invention de rpm ou du packager.
http://koji.fedoraproject.org/koji/rpminfo?rpmID=534326
Pas de trace de nm_utils. C'est surement une dépendence indirecte, donc normal que ldd l'affiche.
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: Yum remove considered harmful
> C'est surement une dépendence indirecte
Oui. Et quand on fait "yum remove ..." il vérifie les dépendance indirecte.
Je serait curieux de savoir si quelqu'un a liferea > 1.4 sous Debian et sans libnm-util. Pour sid, ça m'étonnerait que ça soit possible.
[^]Re: Yum remove considered harmful
gnumdk@sarge:~$ ldd /usr/bin/liferea-bin |grep libnm
libnm_glib.so.0 => /usr/lib/libnm_glib.so.0 (0xb76b0000)
gnumdk@sarge:~$ apt-cache policy liferea
liferea:
Installé : 1.4.15-1
Candidat : 1.4.15-1
Table de version :
*** 1.4.15-1 0
500 http://ftp.fr.debian.org sid/main Packages
100 /var/lib/dpkg/status
gnumdk@sarge:~$
Agogo
[^]Re: Yum remove considered harmful
La dépendance de liferea pour libnm-util vient de libnm-glib. Cette dépendance est dans NetworkManager 7.0 et non dans NetworkManager 6.6.
Fedora 8 utilise NM 7.0, Debian sid utilise NM 6.6. En passant, Ubuntu utilise aussi NM 6.6.
$ ldd /usr/lib64/libnm_glib.so.0.0.0 | grep nmlibnm-util.so.0 => /usr/lib64/libnm-util.so.0 (0x00002aaaaacd0000)
Et chez toi ?
Mais on s'égare. Es-ce que rpm ou Fedora ajouter libnm-utils à liferea et c'est de trop ? Je ne crois pas. Et comme le dit un autre plus haut, c'est une dépendance indirecte (qui vient de libnm_glib (pour NM 7.0)). Bref, pas lié au packaging de liferea.
[^]Re: Yum remove considered harmful
C'est con, mais ses dépendances sont obligatoires.
C'est le boulot du mainteneur du paquet de faire en sorte que ce genre de dependance ne soit pas obligatoire, typiquement, patcher le programme pour que la dependance devienne optionnelle.
[^]Re: Yum remove considered harmful
> C'est le boulot du mainteneur du paquet de faire en sorte que ce genre de dependance ne soit pas obligatoire, typiquement, patcher le programme pour que la dependance devienne optionnelle.
Le packager a décidé que liferea utilise NetworkManager. Je ne sais pas pourquoi, tu peux lui demander si tu veux.
Notons que par défaut liferea utilise NetworkManager. Il faut spécifier --disable-nm pour que ça ne soit pas le cas.
Mais si l'upstream a décidé d'utiliser NetworkManager, il doit y avoir de bonnes raisons.
[^]Re: Yum remove considered harmful
En passant, si tu veux une distribution où tu peux dire que tu veux l'utilisation ou non de bidule ou machin, utilise Gentoo (en compilant).
Mais n'utilise pas Fedora ni Debian.
[^]Re: Yum remove considered harmful
> C'est le boulot du mainteneur du paquet de faire en sorte que ce genre de dependance ne soit pas obligatoire, typiquement, patcher le programme pour que la dependance devienne optionnelle.
Fun, cette "obligation" (selon toi) n'est pas faite chez Debian :
http://packages.debian.org/sid/liferea
Demande "network management framework". Comme Fedora...
M'enfin, vous avez trouvé un os ronger, profitez en.
[^]Re: Yum remove considered harmful
Tu pourrais au moins citer en entier...
Demande "network management framework (GLib shared library)"
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: Yum remove considered harmful
Ben justement, il depend de la lib, pas de network-manager.
Cette obligation d'avoir network-manager pour utiliser liferea n'est donc meme pas une obligation upstream, et Fedora a encore moins d'excuse de creer cette dependance.
[^]Re: Yum remove considered harmful
J'abandonne. Vous avez trouvé un os à ronger.
Sûr que Debian à une pile de connerie dans ce goût.
Comment on fait pour compiler un module sous Debian ?
Ben on installe tous les sources du noyau...
Et ce n'est pas 1 Mo de pris sur le disque (comme pour libnm-util qui n'est pas dans un paquet séparé), mais 100 Mo.
Mais vous avez raison. Fedora aurait dû faire un paquet pour libnm-glib, un autre pour libnm-util et un autre pour NM. Fedora aurait gagné 1 Mo.
Tiens, pour F9, il n'y a plus qu'un dico. Et pour Debian ?
Ici Fedora gagne 20 Mo.
Mais vous avez raison. Fedora aurait dû faire un paquet pour libnm-glib, un autre pour libnm-util et un autre pour NM. Fedora aurait gagné 1 Mo.
Un petit truc "amusant", lorsqu'on installe plusieurs entête du noyau linux, (par exemple la version 2.6.24.3-50.fc8, 2.6.24.4-64.fc8, etc) Fedora fait des liens hards sur les fichiers identiques (ce qui est le cas pour 90 % des fichiers). C'est encore 20 Mo de gagné.
Mais vous avez raison. Fedora aurait dû faire un paquet pour libnm-glib, un autre pour libnm-util et un autre pour NM. Fedora aurait gagné 1 Mo.
Etc.
Je vous souhaite bien du plaisir à ronger votre os.
[^]Re: Yum remove considered harmful
Ne pas installer un paquet d'une bibliothèque ou d'un exécutable n'a pas comme seul objectif de gagner de l'espace disque. Ca permet aussi de ne pas subir les conséquences d'une faille de sécurité découverte dans le paquet en question.
[^]Re: Yum remove considered harmful
Si la librairie n'est pas utilisée...
[^]Re: Yum remove considered harmful
Revenons plutôt au cas de network-manager qui n'est pas une bibliothèque. Je ne connais pas dans le détail le fonctionnement de ce logiciel mais il semble bien qu'il y ait un processus qui tourne sous l'identité root. Dans ce cas, paquet installé mais non utile signifie bien faille de sécurité potentielle supplémentaire.
[^]Re: Yum remove considered harmful
Semi-bonne remarque. Sous Fedora le service NetworkManager n'est pas activé par défaut (contrairement à Ubuntu il me semble).
Ceci dit, ça va peut-être changer pour F9 et je ne sais pas ce qu'il en est.
[^]Re: Yum remove considered harmful
Les NOUVEAUX paquets suivants seront installés :
dhcdbd iputils-arping libiw29 libnl1 libnm-util0 network-manager
network-manager-gnome network-manager-openvpn network-manager-openvpn-gnome
network-manager-vpnc network-manager-vpnc-gnome openvpn resolvconf vpnc
wpasupplicant
Voila ce qu'implique l'installation de network manager... Alors t'es mignon, mais si t'es pas capable de voir que la politique de packaging de Fedora est merdique...
Ca fait des années que Mandrake/riva fait plus ou moins pareil que Debian.
Les pires, c'est Suse, mais d'après un mec qui bossait la bas, c'est parce qu'ils utilisent des outils de construction automatique de packages que c'est aussi merdique chez eux.
Agogo
[^]Re: Yum remove considered harmful
> Alors t'es mignon, mais si t'es pas capable de voir que la politique de packaging de Fedora est merdique...
Tu as brillanment fait la démonstration
$ rpm -q dhcdbd iputils-arping libiw29 libnl1 libnm-util0 network-manager network-manager-gnome network-manager-openvpn network-manager-openvpn-gnome network-manager-vpnc network-manager-vpnc-gnome openvpn resolvconf vpnc wpasupplicantle paquetage dhcdbd n'est pas installé
le paquetage iputils-arping n'est pas installé
le paquetage libiw29 n'est pas installé
le paquetage libnl1 n'est pas installé
le paquetage libnm-util0 n'est pas installé
le paquetage network-manager n'est pas installé
le paquetage network-manager-gnome n'est pas installé
le paquetage network-manager-openvpn n'est pas installé
le paquetage network-manager-openvpn-gnome n'est pas installé
le paquetage network-manager-vpnc n'est pas installé
le paquetage network-manager-vpnc-gnome n'est pas installé
le paquetage openvpn n'est pas installé
le paquetage resolvconf n'est pas installé
le paquetage vpnc n'est pas installé
le paquetage wpasupplicant n'est pas installé
C'est claire, le packaging de Fedora est merdique.
En passant dans Fedora, il y a :
- NetworkManager
- NetworkManager-devel
- NetworkManager-glib
- NetworkManager-glib-devel
- NetworkManager-gnome
- NetworkManager-openvpn
- NetworkManager-vpnc
Oh, mais comme c'est étrange... Quand on installe NetworkManager sous Fedora, on n'est pas obligé d'installer NetworkManager-gnome, NetworkManager-vpnc, etc.
Alors t'es mignon, mais si t'es pas capable de voir que la politique de packaging de Mandriva est merdique...
[^]Re: Yum remove considered harmful
Comment on fait pour compiler un module sous Debian ?
Ben on installe tous les sources du noyau...
Ben non justement :/
Debian dispose d'un outil exprès pour ça, module-assistant, qui s'occupe de tout préparer lui même, outils de build, packages nécessaires etc. Et il ne télécharge que les en-têtes du noyau (paquet linux-headers-`uname -r`), jamais les sources complètes (en tout cas ça ne m'est jamais arrivé, mais tu as peut-être une expérience différente).
[^]Re: Yum remove considered harmful
Tu peux donner plus d'info (un lien par exemple) pour que je ne redise pas cette connerie :-)
Quand j'avais testé Debian (il y a longtemps certes), je devais installer kernel-source ou un truc dans ce style.
> Et il ne télécharge que les en-têtes du noyau (paquet linux-headers-`uname -r`)
linux-headers ne permet pas de compiler un module. La libc dépend d'entête de Linux, on les trouve dans linux-headers.
Sous Fedora il y a kernel-headers (requis par glibc-headers) et pas suffisant pour compiler un module et il y a kernel-devel (suffisant pour compiler un module).
$ rpm -q -i kernel-devel
...
Summary : Development package for building kernel modules to match the kernel
Description :
This package provides kernel headers and makefiles sufficient to build modules
against the kernel package.
$ rpm -q -i kernel-headers
....
Summary : Header files for the Linux kernel for use by glibc
Description :
Kernel-headers includes the C header files that specify the interface
between the Linux kernel and userspace libraries and programs.
[^]Re: Yum remove considered harmful
Je confirme que sous debian, on n'installe pas toutes les sources du noyau pour compiler un module mais seulement les headers.
[^]Re: Yum remove considered harmful
http://packages.debian.org/sid/linux-headers-2.6.24-1-486 :
Header files for Linux 2.6.24 on x86
This package provides the architecture-specific kernel header files for Linux kernel 2.6.24 on x86 and compatible machines, generally used for building out-of-tree kernel modules. These files are going to be installed into /usr/src/linux-headers-2.6.24-1-486, and can be used for building modules that load into the kernel provided by the linux-image-2.6.24-1-486 package.
[^]Re: Yum remove considered harmful
Merci pour l'info.
[^]Re: Yum remove considered harmful
http://packages.debian.org/unstable/devel/module-assistant
À première vue c'est module assistant qui sait si tu as besoin des sources ou pas. Moi je compilais Madwifi juste avec les headers.
Et si vous voulez faire la guerre
Payez-la de votre peau
[^]Re: Yum remove considered harmful
Tu peux donner plus d'info (un lien par exemple) pour que je ne redise pas cette connerie :-)
Un lien non pas vraiment, par contre:
# uname -a
Linux nnoirben 2.6.24-1-686 #1 SMP Mon Feb 11 14:37:45 UTC 2008 i686 GNU/Linux
# dpkg -l | grep linux-source
# module-assistant prepare
[...]
The following extra packages will be installed:
linux-headers-2.6.24-1-common linux-kbuild-2.6.24
The following NEW packages will be installed:
linux-headers-2.6.24-1-686 linux-headers-2.6.24-1-common linux-kbuild-2.6.24
[...]
Et il n'installe donc pas linux-source-2.6.24
Quand j'avais testé Debian (il y a longtemps certes), je devais installer kernel-source ou un truc dans ce style.
Ah bah du coup, ça fait déjà un bon bout de temps, vu que Debian a carrément changé de convetion pour les noms des paquets (de kernel-* vers linux-*, histoire d'être kernel-agnostic) depuis.
linux-headers ne permet pas de compiler un module.
Voir plus haut, le paquet linux-headers (qui est un paquet virtuel fourni par linux-headers-2.6.24 par exemple) suffit tout à fait pour compiler un module kernel sous Debian.
[^]Re: Yum remove considered harmful
"on ne peut pas demander à un simple utilisateur d'avoir une connaissance approfondie de son système"
Oui mais non...l'auteur du billet n'est pas un débutant il est même un bon programmeur, informaticien de profession. Il a été à une époque, et est peut être toujours un développeur sur Gnome (Gdesklets entre autre).
Autant je sais que ces avis peuvent parfois être assez tranchés, autant techniquement parlant il est plus que compétent.
[^]Re: Yum remove considered harmful
Il est toujours développeur chez GNOME, c'est lui qui maintient glibtop et gnome-system-monitor.
On peut-être très compétent techniquement, et vouloir utiliser sa machine en tant que simple utilisateur. C'est une des raisons pour laquelle beaucoup d'utilisateurs de Debian également très compétents pour certains sont passés à Ubuntu.
Là, notre ami a installé fedora, fait mumuse puis basta, pas de rapports de bogues, etc ... il a écrit un billet comme l'aurait fait un simple utilisateur frustré.
Tu lis le billet sans savoir qui l'a écrit, bien fin celui qui me dira que son auteur est un hacker confirmé !
Derrière le hacker, se cache un être humain ! (enfin, on peut se le demander pour certains d'entre eux ^^^)
[^]Re: Yum remove considered harmful
Je suis bien daccord avec toi...je ne voulais pas descendre ainsi l'ami Benoît mais il est clair qu'il nous a fait une petite poussé de colère là, comme un sale gosse ;-)
Mais on ne peut pas dire que ce ne soit complètement idiot...vu ce que cela provoque et ce qui en découle.
A mon sens c'est tout aussi constructif qu'un rapport de bug. Il aurait été nul de ne pas partager son expérience mais là au moins il l'a fait.
Après, dans la forme...oui il a plutôt tendance à dégainer le lance-flamme et à arroser le voisinage avant de chercher à recueillir des avis...c'est un style :-D
[^]Re: Yum remove considered harmful
> yum a un (très) gros problème dans la gestion des dépendances au moment de supprimer un paquet.
Tu peux sourcer ?
> Si je supprime A, je m'attends à ce que yum conserve C, mais là yum a un comportement stupide. A et C ayant été installé ensemble, yum va supprimer A, puis C et logiquement B puisque C va être supprimé.
Tu inventes ou quoi ?
Certes il y a du FUD sur rpm. Mais ajoute pas du FUD sur yum. Ou alors source.
[root@one SRPMS]# yum install fuse-smb
...
Package Arch Version Repository Size
Installing:
fuse-smb x86_64 0.8.7-1.fc8 updates 43 k
Installing for dependencies:
fuse-libs x86_64 2.7.3-2.fc8 updates 70 k
...
Installed: fuse-smb.x86_64 0:0.8.7-1.fc8
Dependency Installed: fuse-libs.x86_64 0:2.7.3-2.fc8
Complete!
[root@one SRPMS]# yum install fuse-s3fs
Package Arch Version Repository Size
Installing:
fuse-s3fs noarch 0.4-9.fc8 updates 23 k
Installing for dependencies:
fuse-python x86_64 0.2-5.fc8 fedora 76 k
...
Installed: fuse-s3fs.noarch 0:0.4-9.fc8
Dependency Installed: fuse-python.x86_64 0:0.2-5.fc8
Complete!
[root@one SRPMS]# yum remove fuse-smb
...
Package Arch Version Repository Size
Removing:
fuse-smb x86_64 0.8.7-1.fc8 installed 98 k
...
Removed: fuse-smb.x86_64 0:0.8.7-1.fc8
Complete!
Tu m'expliques ?
Ça ne fait pas ce que tu dis.
[^]Re: Yum remove considered harmful
> je rejoins l'auteur du billet sur ce point: ce comportement est INACCEPTABLE.
Ce n'est pas un comportement, c'est au pire un bug. Une dépendance de trop de codé dans le fichier .spec du rpm par le développeur ! Ce n'est pas un truc qu'a ajouter automatique rpm ou yum ou pirut ou autre.
Perso, je trouve INACCEPTABLE que tu chies une pendule à cause de (peut-être) un bug. Pirut/yum et rpm ont fait leur boulot correctement. Sinon prouve le contraire !
Et PackageKit que tu adoubes ferait la même chose si on lui demande de virer gnome-media.
Alors soit cohérent et dit que PackageKit a un comportement INACCEPTABLE.
Idem pour apt.
[^]Re: Yum remove considered harmful
A aucun moment, je n'ai incrimé RPM ni Pirut/Yumex/packageKit , j'ai même souligné la cohérence du fonctionnement de Pirut.
Tu as 3 raisons pour laquelle yum remove fout le bordel
* des paquets trop monolithiques, du genre NetworkManager ou Alsa-lib (supprimer cette dernière entraine avec elle GNOME et Xorg ...)
==> aux packagers de corriger si possible (ce qui n'est pas toujours le cas)
* PEBCAK: certains paquets ne doivent pas être désinstallé !
==> le plugin yum-protect-packages qui protège les paquets de base ainsi que ceux spécifier par l'utilisateur.
* des coins obscurs ou le résolveur de dépendances de yum s*cks. C'est rare mais ça arrive.
Je me suis extrêmement mal exprimé, mais ce qui s*cks, c'est que yum permet à l'utilisateur de flinguer trop facilement son système.
Dans mon explication simpliste, j'aurais du rajouter "dans certains cas, il arrive que yum ".
Supprimer le groupe "son et vidéo" ne doit pas emporter avec lui le bureau tout entier !
http://forums.fedora-fr.org/search.php?search_id=232036840&a(...)
Quant au titre, il était délibérement provocateur (un clin d'oeil à Dijkstra), les utilisateurs font trop souvent des yum remove sans même jeter un coup d'oeil sur ce qui va être supprimé.
[^]Re: Yum remove considered harmful
Là je suis pas trop d'accord. C'est pas la faute de yum si tu lui dis de supprimer un élément essentiel (genre alsa-lib) et qu'il le fait, et que ça te flingue le système. Sur ma Mandriva, faire la même chose me demande confirmation pour supprimer 55 packages... Je me doute alors que ça doit être un composant essentiel...
Non, le bug c'est plus que supprimer gnome-media vire tout GNOME (ça n'arrive pas sous Mandriva), et qu'il a l'air d'être difficile de savoir si Pirut a pris en compte ou pas tes manipulations...
Je ne sais pas comment ça se passe sous Fedora (j'utilise yum en ligne de commande, donc je ne me souviens plus trop de comment est gérée l'installation/désinstallation de packages en mode graphique).
Sous Mandriva, comme tu peux faire de la sélection fine de packages, un clic pour désinstaller un package t'informe immédiatement des packages qui en dépendent et qui seront supprimés si tu confirmes la suppression. Ainsi tu limites les risques d'erreur. Ça se passe comment sous Fedora ?
[^]Re: Yum remove considered harmful
> Sur ma Mandriva, faire la même chose me demande confirmation pour supprimer 55 packages... Je me doute alors que ça doit être un composant essentiel...
# yum remove alsa-lib
...
Removing:
alsa-lib x86_64 1.0.15-1.fc8 installed 1.1 M
Removing for dependencies:
ImageMagick x86_64 6.3.5.9-1.fc8 installed 13 M
suivit de 222 lignes dans ce goût
Transaction Summary
=============================================================================
Install 0 Package(s)
Update 0 Package(s)
Remove 224 Package(s)
Is this ok [y/N]:
Si après t'es assez con pour répondre 'y', que veux-tu que yum y fasse...
[^]Re: Yum remove considered harmful
Removing:
alsa-lib x86_64 1.0.15-1.fc8 installed 1.1 M
Removing for dependencies:
ImageMagick x86_64 6.3.5.9-1.fc8 installed 13 M
ImageMagick qui a une dépendance sur alsa-lib, l'exemple est assez cocasse du coup :)
[^]Re: Yum remove considered harmful
Fait "apt-get|urpmi|etc remove alsa-lib" et tu verras d'autres exemple "cocasses".
[^]Re: Yum remove considered harmful
Ben non, APT me supprime des paquets qui ont besoin de faire du son, logique. Après sur un desktop, forcément ça en fait beaucoup, mais il ne me vire pas ImageMagick (lui).
[^]Re: Yum remove considered harmful
Ta démonstration de la supériorité de apt est incontestable.
Oyé Oyé, apt ne vire pas ImageMagick lorsqu'on vire alsa-lib.
Il vire quasiment tout gnome, il vire quasiment tout KDE (suffit de virer arts pour virer KDE), etc. Mais, il ne vire pas ImageMagick. Super.
[^]Re: Yum remove considered harmful
un apt-get remove .*libasound.* me supprime:
- gnome-applets
- totem
- gnome-media
J'appelle pas ce tout gnome...
Agogo
[^]Re: Yum remove considered harmful
quelle mauvaise fois.
c'est pas parce que Fedora est critiquée sur un point particulier qu'il faut te braquer sur la défensive et nier tout problème tout en cherchant d'autres défauts chez les distribs. Que je sache aucune distrib n'est parfaite, ce n'est pas parce qu'un point est souligné sur Fedora qu'on affirme la supériorité universelle d'une autre distrib.
[^]Re: Yum remove considered harmful
C'est un raccourcis... je préfère ne pas dire ce que j'en pense.
Les gens critiquent Fedora, qui car liferea dépend de libnm-util, qui car la suppression de gnome-media supprime beaucoup d'autres paquets, qui car Mandriva splite NetworkManager mais oublie de remarquer que Fedora fait aussi de même, etc.
Tu peux avoir le critère "minimum de dépendance". Si tu veux te faire un système mini (pour l'embarqué, etc) c'est un critère très important. Mais dans ce cas, Gentoo fait merveille et c'est la bonne distribution à utiliser si on a ce critère. Donc au final on a une critique de Fedora sur des critères Gentoo... Désolé, mais Fedora ne concurrence pas Gentoo (ni Debian, ni Mandriva d'ailleurs).
Es-ce que le minimum de dépendance c'est forcément bien ? Bof. C'est un des objectifs à poursuivre, c'est clair. Mais ce n'est pas le seul.
Par exemple je viens de voir que si j'installer fuse-s3fs, le paquet fuse n'est pas installé. On peut dire que fuse-s3fs n'en a pas besoin, au lancement il verra qu'il n'y a pas fusermount, fera un joli warning (ce qu'il fait), et c'est terminé.
Sauf que ça ne marche pas... (donc je vais faire un rapport de bug :-)).
D'un point de vu strict, gnome-volume-manager n'a pas besoin de gnome-media. Comme fuse-s3fs n'a pas besoin de fuse (on peut faire des trucs avec fuse-s3fs sans avoir fuse).
Sans être le développeur/packageur de gnome-volume-manager, on envisage vite la raison du "Require: gnome-media". Peut-être (c'est une supposition de ma part) que gnome-volume-manager a une option pour ouvrir automatiquement un CD audio. Que ce passe-t-il si gnome-media n'est pas installé dans ce cas ?
Il ne se passe peut-être rien de grave, mais j'image que Fedora a décidé que gnome-media est nécessaire pour une bonne utilisation de gnome-volume-manager.
C'est un choix "politique", que pour ma part je ne trouve pas génial (bien au contraire), mais c'est choix "politique" (j'image en fait que c'est seulement une conséquence "historique"). Ça n'a rien à voir avec yum ou rpm ou pirut.
Si j'en fais un rapport de bug, je ne serait pas surpris qu'il soit acceuilli favorablement. Bref, au pire, c'est seulement un bug de packaging. Voila, c'est tout. Mais d'autre vont en conclure que yum est de la merde, en se basant sur seulement un paquet que tout le packaging de Fedora est pourri, etc. Et là c'est franchement pousser.
Quand Ubuntu a fait une mise à jour de Xorg de triste mémoire, je n'ai pas dit qu'Ubuntu était de la merde, etc. C'était un bug comme il en existe des centaines dans toutes distributions.
[^]Re: Yum remove considered harmful
C'est bizarre tous ces problème de dépendances quand on sait que Slackware marche très bien et cela sans gestion de dépendance.
(ok ok il y a beaucoup moins de paquet)
Et si vous voulez faire la guerre
Payez-la de votre peau
[^]Re: Yum remove considered harmful
> gnome-volume-manager a une option pour ouvrir automatiquement un CD audio. Que ce passe-t-il si gnome-media n'est pas installé dans ce cas ?
Sous Debian, il y a un joli champ Recommends:, qui fait parfaitement l'affaire pour des trucs comme ça
[^]Re: Yum remove considered harmful
Ta démonstration de la supériorité de apt est incontestable.
Oyé Oyé, apt ne vire pas ImageMagick lorsqu'on vire alsa-lib.
Il vire quasiment tout gnome, il vire quasiment tout KDE (suffit de virer arts pour virer KDE), etc. Mais, il ne vire pas ImageMagick. Super.
T'es un grand calme, Toi, non ?
Le type essaye juste de dire que le paquet est mal branlé (j'entends "pas fait au mieux" ou perfectible si Tu préfères), pas que Tu vas arrêter de vivre parcequ'yum est pas bien, il ne dit rien sur yum, T'es seul dans Ton trip (partage Ta drogue).
Arrête de toujours vouloir comparer "mon mien mieux que Ton Tien"
(encore que il faut avouer que ce journal porte bien son nom, on Te stresse alègrement aujourd'hui ;D et d'autres font de la comparaison "mon package mieux que Ton Tien")
Ce message aurait très bien pu être au second degré.
[^]Re: Yum remove considered harmful
> Je ne sais pas comment ça se passe sous Fedora (j'utilise yum en ligne de commande, donc je ne me souviens plus trop de comment est gérée l'installation/désinstallation de packages en mode graphique).
Pirut, yumex, packagekit utilise yum. Donc ça se passe de la même façon.
> Ça se passe comment sous Fedora ?
Pareil. Il te met la liste de ce qui va être ajouté/mise à jour/supprimé et demande confirmation avant de faire toute action.
[^]Re: Yum remove considered harmful
Faut arreter de dire des conneries, supprimer gnome-media ne supprime pas TOUT GNOME.
[root@iema01 ~]# yum remove gnome-media
Loading "dellsysidplugin" plugin
Setting up Remove Process
planetcore 100% |=========================| 1.9 kB 00:00
fedora 100% |=========================| 2.1 kB 00:00
planetccrma 100% |=========================| 1.9 kB 00:00
adobe-linux-i386 100% |=========================| 951 B 00:00
updates 100% |=========================| 2.3 kB 00:00
freshrpms 100% |=========================| 1.9 kB 00:00
dribble 100% |=========================| 951 B 00:00
Resolving Dependencies
--> Running transaction check
---> Package gnome-media.x86_64 0:2.20.1-3.fc8 set to be erased
--> Processing Dependency: libgnome-media-profiles.so.0()(64bit) for package: gnome-python2-totem
--> Processing Dependency: libgnome-media-profiles.so.0()(64bit) for package: sound-juicer
--> Processing Dependency: libgnome-media-profiles.so.0()(64bit) for package: rhythmbox
--> Processing Dependency: gnome-media for package: gnome-volume-manager
--> Running transaction check
---> Package gnome-volume-manager.x86_64 0:2.17.0-8.fc8 set to be erased
--> Processing Dependency: gnome-volume-manager for package: gnome-session
---> Package gnome-python2-totem.x86_64 0:2.20.0-1.fc8 set to be erased
--> Processing Dependency: gnome-python2-totem for package: serpentine
---> Package sound-juicer.x86_64 0:2.20.1-1.fc8 set to be erased
---> Package rhythmbox.x86_64 0:0.11.3-7.fc8 set to be erased
--> Running transaction check
---> Package gnome-session.x86_64 0:2.20.3-1.fc8 set to be erased
--> Processing Dependency: gnome-session >= 2.19.6-5 for package: compiz-gnome
---> Package serpentine.noarch 0:0.9-2.fc8 set to be erased
--> Running transaction check
---> Package compiz-gnome.x86_64 0:0.6.2-3.fc8 set to be erased
--> Finished Dependency Resolution
Dependencies Resolved
=============================================================================
Package Arch Version Repository Size
=============================================================================
Removing:
gnome-media x86_64 2.20.1-3.fc8 installed 4.8 M
Removing for dependencies:
compiz-gnome x86_64 0.6.2-3.fc8 installed 1.2 M
gnome-python2-totem x86_64 2.20.0-1.fc8 installed 29 k
gnome-session x86_64 2.20.3-1.fc8 installed 1.7 M
gnome-volume-manager x86_64 2.17.0-8.fc8 installed 2.1 M
rhythmbox x86_64 0.11.3-7.fc8 installed 10 M
serpentine noarch 0.9-2.fc8 installed 929 k
sound-juicer x86_64 2.20.1-1.fc8 installed 3.0 M
Transaction Summary
=============================================================================
Install 0 Package(s)
Update 0 Package(s)
Remove 8 Package(s)
Is this ok [y/N]: n
Exiting on user Command
Complete!
[root@iema01 ~]#
Les dépendances sont un choix des développeurs upstream et des packagers.
Il n'y a rien ici à critiquer sur le comportement de RPM/Yum/Pirut car ils affichent un récapitulatif et demande confirmation avant d'installer ou supprimer des dépendances.
Personellement pour une station de travail, je préfère de loin l'approche Fedora qui installe un environnement de bureau complet et cohérent pour obtenir un système convivial et fonctionnel au final plutot que l'approche Debian qui crée un maximum de paquets et qui m'oblige à être un expert de haut niveau pour savoir quoi installer afin d'avoir mes clé usb qui monte automatiquement sur le bureau ou le lecteur CD audio qui se lance automatiquement lorsque j'insère un CD.
En tout cas je plains l'entreprise qui a embauché l'informaticien à l'origine de cette news à troll... Savoir ces serveurs géré par un gus qui clique au hazard sur des cases à cocher ya de quoi faire des cauchemard la nuit !! Quoique... c'est pas les admins windows qui manque dans les entreprises...
[^]Re: Yum remove considered harmful
> http://forums.fedora-fr.org/search.php?search_id=232036840&a(...)
Votre recherche n'a renvoyé aucun résultat.
> Tu as 3 raisons pour laquelle yum remove fout le bordel
Pourquoi tu fais ce que tu reproches aux autres ?
Ce n'est pas "yum remove" le problème car le problème tu l'as avec rpm ou pirut ou apt ou PackageKit ou n'importe quoi.
Notre ami Benoît Dejean voit le groupe "Sound and Video" et n'en veut pas. Donc il demande sa suppression. Après que Pirut lui informe des conséquences (liste des paquets qui vont être supprimés), il confirme son action.
En quoi Yum ou Pirut ou Rpm ou que sais-je fout le bordel ?
C'est l'utilisateur qui a foutu le bordel.
Il aurait pû voir gnome-media et se dire qu'il n'en veut pas et faire un "yum remove gnome-media" ou "apt-get remove gnome-media" ou "PackageKit remove gnome-media", s'il ne prête pas attention à ce qu'il fait (comme lorsqu'il a utiliser Pirut), il va à la catastrophe.
Je répète encore, mais yum n'a rien à voir ici. C'est seulement un outil qui fait bien son boulot même quand on lui demande une connerie. Et c'est idem pour les autres gestionnaires de paquet.
Imaginons que tu n'utilises pas sed. Tu vois sed dans PackageKit et demande de le virer. Tu ne regardes pas les conséquences et confirme. Ben t'as une méga catastrophe. J'ai pris sed, mais tu peux prendre un autre paquet obscure que tu ne connais pas.
Tu déplaces un problème de packaging pour diaboliser bêtement yum (ou pirut) alors que c'est exactement le même "problème" avec d'autres gestionnaires de paquet. Tu fais comme les gus qui disent que rpm ne sait pas gérer les dépendances car ils ont ajouter 50 000 dépôts plus incompatibles les uns que les autres et fait des "rpm --force" à la pelle.
Ne descend pas aussi bas !
Je veux bien reconnaitre un problème de dépendance en trop. Est-il normal que gnome-volume-manager dépende de gnome-media (à la demande du développeur) ? J'en sais rien, mais la question est pertinante.
Est-il normal que lorsqu'on demande de supprimer 2 paquets avec Pirut il en supprime 50 sans mettre un BIG FAT WARNING ? Effectivement, ce n'est peut-être pas normal. Mais on est alors sur un problème d'ergonomie, d'assistance à l'utilisateur, etc et plus du tout dans le registre "yum a un comportement INACCEPTABLE" (alors que yum fait exactement comme les autres...).
> * des paquets trop monolithiques
Tu mélange encore, c'est un problème de dépendance.
> du genre NetworkManager
Ici :
# yum remove NetworkManager
...
=============================================================================
Package Arch Version Repository Size
=============================================================================
Removing:
NetworkManager x86_64 1:0.7.0-0.6.7.svn3235.fc8 installed 2.3 M
Removing for dependencies:
NetworkManager-glib x86_64 1:0.7.0-0.6.7.svn3235.fc8 installed 106 k
libpurple x86_64 2.4.1-1.fc8 installed 20 M
liferea x86_64 1.4.13-2.fc8 installed 2.2 M
pidgin x86_64 2.4.1-1.fc8 installed 2.3 M
liferea et pidgin utilise libnm-util.so de NetworkManager. Donc ce n'est pas un problème du gestionnaire de paquet qui fait correctement son boulot. Sans NetworkManager, liferea ne marche plus.
Ce qui faut est que ces derniers chargent libnm-util.so à la demande. Ce n'est pas yum/pirut/dpkg/apt/etc qui peut gérer ça.
> Alsa-lib
Si tu veux tout coder en utilisant des modules, n'hésite pas. Mais je te préviens, c'est un boulot gigantesque. Pense qu'il n'y a pas que alsa-lib...
> ==> aux packagers de corriger si possible (ce qui n'est pas toujours le cas)
Les packagers corrigent si c'est un bug manisfeste. Tu fais quoi ici ? Décourager les gens à faire des rapports de bug ?
La rapport de bug pour dépendance superflux sont très très appréciées.
> * PEBCAK: certains paquets ne doivent pas être désinstallé
Et pourquoi ?
> * des coins obscurs ou le résolveur de dépendances de yum s*cks. C'est rare mais ça arrive.
Arrêtes de faire dans le FUD. Source tes info, donne des preuves, donne des exemples, donne un rapport de bug.
Arrêtes de faire dans le FUD !
> Je me suis extrêmement mal exprimé, mais ce qui s*cks, c'est que yum permet à l'utilisateur de flinguer trop facilement son système.
Les autres gestionnaires de paquet aussi. Donc dis que tous les gestionnaires de paquet sucks et arrête de t'en prendre exclusivement à yum ou pirut.
Je sais que tu n'aimes pas pirut. Mais ce n'est pas une raison pour dire des conneries.
> Dans mon explication simpliste, j'aurais du rajouter "dans certains cas, il arrive que yum ".
Dans ce cas tu aurais dû dire "dans certains cas, il arrive que yum, rpm, pirut, packagekit, dpkg, apt, smart, urpmi, etc".
Mais tu ne t'en prends mistérieusement qu'à yum/pirut...
> Supprimer le groupe "son et vidéo" ne doit pas emporter avec lui le bureau tout entier !
On peut considérer que c'est un bug. Mais ce bug n'est pas dans Pirut ou yum, c'est (peut-être) une erreur de packaging comme il en existe nombre et dans toutes les distributions !
Rien de spécifique à yum ou pirut.
> les utilisateurs font trop souvent des yum remove sans même jeter un coup d'oeil sur ce qui va être supprimé.
Et je ne vois pas en quoi PackageKit ou un autre est une réponse à ce problème entre la machine et la chaise.
J'aime beaucoup te lire ici. Mais encore une fois tu t'en prends à Yum et Pirut de façon totalement creuse. Tu fais comme les gus qui disent "rpm sucks" et se refusent à toute réfléxion car ils ont une opportunité de dire "rpm sucks". Toi c'est pareil.
[^]Re: Yum remove considered harmful
> Mais tu ne t'en prends mistérieusement qu'à yum/pirut...
Tu m'apprends quelque chose.
J'adore yum, il est extensible, ubique (on le retrouve dans Mock, Anaconda, pungi etc ...).
> Et je ne vois pas en quoi PackageKit ou un autre est une réponse à ce problème entre la machine et la chaise.
Tu es bien le seul à évoquer PackageKit dans ce sens là.
(pirut) qui est gentillement poussé vers la porte de sortie en tant qu'application standalone par PackageKit
Si tu parles de çà, n'y voit aucun jugement de valeur mais l'expression d'un fait. extrait du wiki de fedoraproject.org :
PackageKit is currently the default GUI package management tool for both GNOME and KDE for the Fedora 9 beta.
http://fedoraproject.org/wiki/Features/PackageKit
Sinon, Pirut/PackageKit/Yumex étant des surcouches à yum, ils sont égaux vis à vis de ce problèmes.
De plus, ça n'a aucun sens de comparer PK et Pirut/Yumex/Synaptic etc ..., ils ne répondent pas à la même question.
> Je sais que tu n'aimes pas pirut. Mais ce n'est pas une raison pour dire des conneries.
Pour l'utilisateur de base, il n'a pas besoin de savoir ce que contient le groupe, c'est le rôle du distributeur de faire des choix cohérents, en ce sens, Pirut fait son boulot, les utilisateurs avancés peuvent passer à Pirut. C'est un choix du distributeur de fournir un outil simple conforme aux HIG de GNOME (si, si, Pirut est conforme)
Là, où tu vois une critique, je vois un compliment. Pirut est consistent avec son cahier des charges, et la simplicité de l'outil est pour moi une qualité (si ce n'était pas le cas, j'utiliserais KDE3 et non pas GNOME)
> Mais encore une fois tu t'en prends à Yum et Pirut de façon totalement creuse
Enfer et damnation, mon travail de sape pour dénigrer yum et Fedora a été démasqué. Je retourne sur ma Manbuntiva pour jouir des bienfaits de apt-urpmi. :o)
[^]Re: Yum remove considered harmful
> Tu es bien le seul à évoquer PackageKit dans ce sens là.
Très bien, oublie PackageKit.
Mais sur quoi tu te bases pour dire que le comportement de "yum remove" est INACCEPTABLE (en majuscule dans le texte) ?
Pour toi il est INACCEPTABLE, mais tout le monde fait pareil...
Donc tous les gestionnaires de paquets sont INACCEPTABLE ?
Ben installe une LSF les les gestionnaires de paquets ont un comportement INACCEPTABLE.
Tu nous sors un truc fumeux sur yum qui prendrait en compte l'historique d'installation des paquets et se mélangerait les crayons lors d'un "yum remove". Tu nous sors ça sans la moindre preuve.
J'ai fait la manip chez moi, ben ce truc fumeux n'existe pas. Et je n'ai pas oublié de te demander plus d'une fois que tu sources cette "information" sur ce comportement.
Je remets tes propos :
le problème n'est pas RPM (qui au passage, vaut bien dpkg), mais en l'occurence yum !
yum a un (très) gros problème dans la gestion des dépendances au moment de supprimer un paquet.
...
mais là yum a un comportement stupide.
...
Pas étonnant qu'avec ce comportement de merde, on fout le boxon sur sa Fedora.
...
mais il a un gros défaut "yum remove"
...
ce comportement est INACCEPTABLE.
...
C'est toi qui écrit ça et sans le moindre argument pertinant.
> Enfer et damnation, mon travail de sape pour dénigrer yum et Fedora a été démasqué.
On peut critiquer Pirut. Par exemple on peut proposer que Pirut (et d'autres) fasse un BIG FAT WARNING lorsque la suppression d'un paquet implique la suppression de 4 fois plus de paquet.
Si la suppression d'un paquet (référencé dans le fichier comps.xml) implique la suppression d'un élément sélectionné ailleurs, il pourrait y avoir un BIG WARNING.
Comme il y a le fichier comps.xml, on pourrait ajouter le fichier critique.xml et si un paquet référencé par critique.xml est demandé à supprimer, pirut (et d'autres) pourrait faire un BIG FAT WARNING et non seulement afficher toujours la même boite de dialogue.
Etc.
Dire que les gardes-fous de Pirut ne sont pas suffisants est tout à fait accèptable vu la mésaventure donné par le blog.
Mais dire des trucs (genre yum a des problèmes de dépendances lors d'un "yum remove") dans le moindre début de preuve, c'est définitivement de la connerie.