Faire n'importe quoi puis reprocher à l'application un fonctionnement correct, c'est n'importe quoi. Si le système ne fonctionne plus convenablement par après, c'est sa faute.
Justement, j'ai l'impression que c'est le fait de permettre de faire n'importe quoi sans faire aucun retour à l'utilisateur qui est critiqué.
En fait, en ayant lu Ton commentaire, j'avais peu envie de lire le lien mais il est très constructif. Il souligne des problèmes que Fedora a tout intérêt à résoudre.
La plupart. (en admettant que j'ai bien compris ce que dit la personne dans son analyse)
Mais (si je ne me trompe pas) le système de paquets a été revu récemment (?) et donc forcément, il faut laisser du temps pour améliorer les choses (et signaler les fonctionnements qui *paraissent* mauvais).
Il me semble que les interfaces graphiques sous debian (qui sont loin d'êtres exemptes de soucis) émettent un warning si Ta déselection entraîne des modifs pour d'autres paquets (genre "attention si Tu fais vraiment ça, ça va faire ça, Tu veux vraiment ou Tu faisais une feinte ?" et perso, je préfère cette approche plutôt que "hey, j'ai fait comme Tu m'as dit mais du coup, j'ai aussi du aussi faire ça", la différence étant que Ta liste de paquets sélectionnés à l'install/update/desinstall/... a été modifiée dans le second cas et que Tu dois la rechecker pour être sûr que c'est dans l'état voulu...)
En même temps, je reprenais les propos de quelqu'un d'autre sur le wwwoueb et je n'ai apparemment pas sû bien mettre en avant que je ne reprenais rien à mon compte : j'ai rien testé, comment pourrais-je critiquer ? Par contre, la première réponse me paraissait un poil partisane : "mais si ça marche et si ça marche pas, c'est sa faute"
tiens cela me rappel un truc sous redhat 8.0 avec apt, apres moulte mise a jour avec rpm je m'apercois que j'ai 4 version de glibc qui cohabitent avec des liens symboliques un peu partout avec toute les versions.
apt installé fraichement je lui demande de desinstaller 3 glibc. et la gros message enorme et il me demande d'ecrire: Yes, i want to do that
y ne marche pas yes non plus, il fallait respecter la casse et bien ecrire toute la phrase. impressionnant
Effectivement, ça fait ça quand on veut supprimer la glibc utilisée et peut être également si on supprime le kernel en cours d'utilisation si je ne me trompes pas.
Le message exact est :
You are about to do something potentially harmful.
To continue type in the phrase "Yes, do as I say!"
Vous êtes sur le point de faire quelque chose de potentiellement dangereux
Pour continuer, tapez la phrase "Oui, faites ce que je vous dis !"
Et il faut effectivement taper toutes les lettres, point d'exclamation y compris (oui, même pour les malheureux administrateurs de debian de l'hexagone avec un clavier français et une locale en ou C.
Il y a retour à l'utilisateur avec un message qui indique explicitement que des paquets vont être supprimer (c'est indiqué deux fois).
L'action est faite que lorsque l'utilisateur a cliqué sur "continué" de la boite qui affiche la liste des paquets qui vont être supprimé (et il est clairement indiqué qu'ils vont être supprimé).
> Il souligne des problèmes que Fedora a tout intérêt à résoudre.
Personne ne sait résoudre le problème entre la machine et la chaise.
Holà, je reprenais les propos du gars qui a fait la critique, je ne saurai pas les prendre à mon compte (Tu sais les mots "j'ai l'impression que" et la forme passive "qui est critiqué"), je n'ai ni le temps ni surtout la motivation de tester une Fedora.
De là à dire que c'est ce type le problème, il y a un pas que je Te laisse faire sans moi.
> De là à dire que c'est ce type le problème, il y a un pas que je Te laisse faire sans moi.
Très juste. La distribution est au service de l'utilisateur et donc doit être adaptée à l'utilisateur. Il y a peut-être un problème d'ergonomie, de retour d'information, de contrôle que l'utilisateur ne fait pas n'importe quoi, etc dans Pirut. Mais ce n'est pas pour autant qu'il faut en conclure que pirut, yum et rpm puent. Surtout qu'il y a eu demande de confirmation avant que l'utilisateur fasse sa connerie.
Que dit l'utilisateur après sa conneries (qu'on peut comprendre) ?
- "Seulement les dépendances et RPM, même 10 ans après, ça ressemble toujours à de l'escroquerie."
C'est un fort de café alors que Pirut/yum/rpm a seulement fait son boulot. Peut-être avec "trop de zèle", mais avec la "bénédiction" de l'utilisateur.
Mon voisin a une ubuntu qu'il casse cycliquement et donc cycliquement je fais fasse à de nouveaux (et vieux aussi) problèmes.
Je ne lui hurle pas (trop) après, par contre, le jour où la distrib incluera plus de garde fous (ou le jour où il appréhendera mieux ce qu'il fait), j'aurai plus de temps pour jouer au djumbé avec lui... (Par contre, effectivement, il ne me sort jamais du "linux, c'est vraiment trop de la merde")
C'est moche.
Fedora vient de perdre un utilisateur qui clique partout sans réfléchir et ne lit pas les avertissements.
Tirons quelques enseignements.
Enseignement technique ; supprimer Gnome alors qu'on est sous Gnome, n'est pas une bonne idée.
Notons que frysk est présent. yum install frysk
...
frysk x86_64 0.2.1-0.fc8 updates
Il y a une mise à jours mais c'est aussi dans la release : yum install --disablerepo=updates frysk
...
frysk x86_64 0.0.1.2007.10.17-1.fc8 fedora
Yum search le trouve : yum search frysk
...
frysk.x86_64 : Frysk execution analysis and debugging tools
frysk-gnome.x86_64 : The GNOME front-end of Frysk
frysk.x86_64 : Frysk execution analysis and debugging tools
frysk-gnome.x86_64 : The GNOME front-end of Frysk
frysk-devel.x86_64 : The development part of Frysk
frysk-devel.i386 : The development part of Frysk
frysk-devel.x86_64 : The development part of Frysk
frysk-devel.i386 : The development part of Frysk
Ben oui, il faut installer frysk-gnome pour avoir un truc dans $PATH.
Systemtap est aussi présent, pas de problème.
je désélectionne aussi "Bureautique/Productivité" (sic) qui selon sa description doit contenir des afficheurs PDF, etc.
Erreur monumentale.
Faisons avec yum, pirut fait la même chose (sauf qu'il y les traductions des noms de groupe) : yum groupremove "Office/Productivity"
...
Removing:
dia x86_64 1:0.96.1-6.fc8 installed 15 M
evince x86_64 2.20.2-1.fc8 installed 3.3 M
openoffice.org-calc x86_64 1:2.3.0-6.11.fc8 installed 21 M
openoffice.org-draw x86_64 1:2.3.0-6.11.fc8 installed 2.9 M
openoffice.org-graphicfilter x86_64 1:2.3.0-6.11.fc8 installed 437 k
openoffice.org-impress x86_64 1:2.3.0-6.11.fc8 installed 4.9 M
openoffice.org-langpack-en x86_64 1:2.3.0-6.11.fc8 installed 21 M
openoffice.org-math x86_64 1:2.3.0-6.11.fc8 installed 3.5 M
openoffice.org-writer x86_64 1:2.3.0-6.11.fc8 installed 7.4 M
openoffice.org-xsltfilter x86_64 1:2.3.0-6.11.fc8 installed 257 k
Je répète, pirut fait la même chose.
Par contre un "yum groupremove 'GNOME Desktop Environment'", c'est une autre histoire, puisque sur mon système (léger), il vire 129 paquets.
Ensuite, il n'y pas de gestion de dépendances entre les méta-paquets
Ben oui il a gestion de dépendance. Si tu demandes à supprimer Gnome et qu'il y a, par exemple, des -devel Gnome (qui ne sont pas référencé par "GNOME Desktop Environment'"), ben il va les virer.
Et ça ne sont pas des méta-paquets, mais des groupes (un groupe de paquet). Il n'y a pas de dépendance codée entre groupe, mais ce n'est pas grave car il y a les dépendances entre paquets.
ça a un peu déselectionner par hasard "Environnement de bureau GNOME", sans me le dire bien sur...
Information utile : Tu n'es pas sous Windows.
Ça n'a pas désélectionner "Environnement de bureau GNOME" car pirut ne le fait que sur demande de l'utilisateur. Par contre via les dépendances rpm ça peut effectivement virer une bonne partie de "Environnement de bureau GNOME".
je lance ce gestionnaire de paquets graphique, il n'arrive logiquement pas à récupérer la liste des paquets: il y a bien un bouton "Annuler" mais il ne fonctionne pas.
Apparament il mache très bien. Tu cliques sur "Annuler" et il ne fait rien. Bref, le bouton porte bien son nom. Pour quitter l'appli, il faut fermer la fenêtre ou faire menu : "Fichier"->"Quitter".
Et là je vois l'installateur de paquets afficher des mise à jour (???)
Je n'y crois pas.
Voila ce qu'affiche Pirut : Sélections de paquetages
Vous avez choisi d'installer ou supprimer les logiciels suivants. Détails : Suppression de :
...
Magnifique: en quelques minutes, 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. J'insiste, je n'ai pas fait n'importe quoi.
T'as demandé la suppression de paquets, cette demande via les dépendances supprimer d'autres paquets.
Seulement les dépendances et RPM, même 10 ans après, ça ressemble toujours à de l'escroquerie.
En fait, tu viens de passer à un système qui gère très bien les dépendances. Mais manifestement tu n'es pas habitué.
Je pense qu'on peut considéré qu'il y a un problème pour ton cas. Pas un problème technique (rpm gère très bien les dépendances) mais de définition des groupes. Virer groupe "Sons et vidéos" vire gnome-media, qui vire gnome-volume-manager, qui vire gnome-session.
La gestion des dépendances est nickel, mais le résultat surprenant.
Oublions le reste.
Le plus intéressant, c'est que ça vient d'un utilisateur Debian. Combien d'heures il a passé sur la doc Debian ? Combien de centaines de page de doc il a lu ? Des tonnes. Mais pour Fedora il est hors de question qu'il lise une "popup".
Sûr que lorsqu'il a un comportement non prévu avec apt, il doit réfléchir pour savoir ce qu'il se passe. Mais avec Fedora il nous tombe de suite un "Seulement les dépendances et RPM, même 10 ans après, ça ressemble toujours à de l'escroquerie" en 2 secondes et sans réfléchir.
Conclusion :
Si vous ne voulez pas Fedora, n'installez pas Fedora.
PS: Il y a apt et synaptic sous Fedora. Sûr qu'avec ses derniers il va trouver la gestion des dépendances nickels...
Mais, au moins pour les suppressions, c'est rpm qui les calcules, ou au moins les impose.
Virer groupe "Sons et vidéos" vire gnome-media, qui vire gnome-volume-manager, qui vire gnome-session.
gniii? Quand je vire une couche supérieure, il vire toutes les couches inférieures ?
Trois possibilités:
- J'ai mal compris
- Tu te trompes (j'espere que c'est une de ses deux la)
- RPM reste un truc tout pourri pour gérer les dépendances.
Pour moi, un gestionnaire de paquets doit faire:
- Si j'installe quelque chose, il installe tous les paquets nécessaires.
- Si je vire quelque chose, il vire tous les paquets qui ont _besoin_ de ce que je vire. A ma connaissance gnome-session n'a pas _besoin_ de gnome-volume-manager...
Je me réponds... ou plutot GeneralZod me répond juste en dessous...
Le gagnant est donc (roulement de tambour....)
RPM (yum en fait mais bon) reste un truc tout pourri pour gérer les dépendances.
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é.
>RPM (yum en fait mais bon) reste un truc tout pourri pour gérer les dépendances.
C'est pas possible une mauvaise foi pareille. Le commentaire plus bas, que tu sites, il dit texto : "Y'a PAS de problème avec RPM, c'est YUM qui merde". Et tu traduis par "C'est RPM qui est pouris" ! Ca c'est du troll de grande classe.
Le plus intéressant, c'est que ça vient d'un utilisateur Debian. Combien d'heures il a passé sur la doc Debian ? Combien de centaines de page de doc il a lu ? Des tonnes.
Tu fais les questions et les réponses maintenant ?(avec réponse partisane donc troll detected)
Ceci dit, IsNotGood met quand même le doigt sur quelque chose en disant ça...
Il y a deux ans, un bon admin a testé Ubuntu, n'a pas réussi à configurer le wifi avec son clicodrome... Donc, il ne fait pas plus d'effort et gueule partout que "Ubuntu, c'est pourri".
Et bien, effectivement, ça me fait bien chier de voir un gars à priori fort en Unix, ne pas être capable de faire un poil d'effort pour trouver le pb et hurler des choses sans fondement (en l'occurence, c'était un pb utilisateur -la fameuse chaise si chère à IsNotGood- et pas un problème de distrib. Quand bien même, la personne dont je parle avait largement le niveau pour savoir si ça venait de l'appli utilisée et donc plutôt blamer gnome ou si ça venait d'autre part)
Effectivement, surtout au niveau des distribs grand public, on a un problème de syndrôme windowsien ("je veux que ça marche out of the box") même de la part de personne qui à priori devrait mieux identifier les problèmes...
en même temps, on nous bassine tout le temps avec "ubuntu c'est génial il suffit de faire deux coups de cuillère à pot et hop tout marche bien mieux que n'importe quel distrib" qu'on le prend au mot.
Perso, quand j'ai testé ubuntu j'ai fait ça.
Je me suis dit "je ne vais pas profiter de mon exp sous linux pour faire quelque chose, je vais me mettre à la place de quelqu'un qui n'y connais rien"... Ben je suis finalement resté sur ma debian XD.
Ben non ce n'est pas dommageable. Il faut sortir de cette optique élitiste/il faut éduquer les utilisateurs : si l'utilisateur n'y arrive pas ou fait une erreur, il faut modifier le système.
Après, ce n'est pas toujours possible car :
- les utilisateurs attendent des choses différentes donc forcément, concevoir un système pour plusieurs utilisateurs, c'est trouver un juste milieu.
- le système est lié par des contraintes techniques/sécurité. L'ordinateur ne sait pas encore lire dans notre esprit, il faut apprendre à utiliser un clavier et une souris.
Mais en dehors de ces 2 points, je le dis et le répète : si l'utilisateur n'y arrive pas, c'est un bug. A fortiori si tous les utilisateurs n'y arrivent pas. Mais c'est sûr que c'est plus facile de se réfugier derrière le "Ils sont tous bêtes" (et je suis leur chef)
Mes livres CC By-SA : https://ploum.net/livres.html
Aucun élitisme dans mon propos, si Tu regardes plus haut, je défends justement les mêmes choses que Toi : on ne peut pas blamer l'auteur de l'article qui souligne un bug (ok, léger, y a moyen de vérifier avant de tout pêter) mais je vois un différence entre une personne forte techniquement qui fait un billet incisif mais qui montre les problèmes et permet aux gens d'améliorer et une personne forte techniquement qui crie à tout monde "c'est pourri" sans plus de fondement et fait "peur" aux gens quand à l'utilisabilité de linux.
Dans les deux cas, l'utilisateur est fort techniquement (mais veut se comporter en user lambda - ce n'est pas un soucis), le premier dit les choses un peu agressivement mais de manière constructive, le second n'a aucune constructivité et décridibilise une distrib (si ce n'est linux au sens très large : le vrai utilisateur lambda fait peu de différence entre Ubuntu, Fedora, kernel, logiciel libre ou même les *BSD et confond le tout allègrement).
Tu vois ce que je reproche (sans élitisme, vraiment) ?
oui, merci pour ton commentaire. Je n'avais pas du tout compris ça comme ça. On est parfaitement d'accord sur le fond : le billet en lien relève un réel problème qui doit être corrigé.
Sur la forme, je trouve que c'est un vulgaire troll et ça me rassure de voir qu'on en revient à un bon vieux APT vs RPM :-)
Mes livres CC By-SA : https://ploum.net/livres.html
ça me rassure de voir qu'on en revient à un bon vieux APT vs RPM
Ce troll montre surtout l'ignorance de ceux qui crachent sur RPM : il ne s'agit pas franchement de la même chose, RPM est plutôt au niveau des .deb (format) et de dpkg ! Beaucoup de choses qui sont reprochés à RPM par ceux qui n'y connaissent rien vient souvent de problèmes : 1) d'empaquetage, les dépendances sont mal listées, 2) de gestion des dépendances par urpmi/yum/yast/ etc.
Amis de linuxfr, si vous voulez faire du troll de qualité, cessez de tout confondre et de dire n'importe quoi sur RPM (d'ailleurs les gens qui en parlent n'ont souvent pas approché un RPM depuis le Mandrake 9.0)
(d'ailleurs les gens qui en parlent n'ont souvent pas approché un RPM depuis le Mandrake 9.0)
C'est pas faux (au moins dans mon cas). Mais pourquoi changer quand on est satisfait de ce qu'on a (et que c'est le mieux de toutes façons) ?
Sinon, juste pour savoir, tu a réussi à le faire fonctionner ton media center Mandriva ? J'ai des CD d'install Debian si tu veux.... :P
Qu'est-ce qui va autour ? Franchement, je ne vois pas. Si les codecs pouvaient être un souci il y a 5 ans, ça fait depuis longtemps que ça n'en est plus un !
Si encore tu m'avais dit que c'était la configuration de la télécommande, je comprends, c'est toujours galère.
Ah mais mon cher ami, j'ai trouvé d'où venaient les problèmes de la télévision. Il s'agissait en fait d'un conflit d'IRQ avec la carte graphique. Tout roule maintenant !
Pour ceux qui répondent à l'ami Pipo, vous devez savoir que c'est une remarque perso ;-)
> Hmm, marche très bien sous Debian... Yum Suxor ? ;)
Rien à voir, Yum et rpm marchent très bien.
Gnome-volume-manager a "Requires: gnome-media". C'est un choix du développeur (c'est peut-être aussi une nécessité, je n'en sais rien).
Gnome-session a "Requires: gnome-volume-manager". C'est un choix du développeur (c'est peut-être aussi une nécessité, je n'en sais rien).
Donc lorsque gnome-media est viré, gnome-session est viré aussi. Yum, pirut ou rpm font parfaitement leur boulot. Et PackageKit ferait la même chose. Et apt (qui existe sous Fedora) ferait aussi exactement la même chose.
Par contre, on peut se demander qui les "Requires: gnome-media" ou "gnome-volume-manager" sont vraiment nécessaires. Il faudrait le demander au développeur.
Il faudrait demander au packager plutôt qu'au développeur...
Sous Mandriva Linux 2008.1: [root@alcor trunk]# urpme --test gnome-media
Pour satisfaire les dépendances, les 4 paquetages suivants vont être désinstallés (20Mo):
gnome-media-2.20.1-1mdv2008.0.i586
(en raison du manque de libcddb-slave2.so.0,
en raison du manque de libgnome-media-profiles.so.0)
libcddb-slave2_0-2.20.1-1mdv2008.0.i586
(car gnome-media >= 2.20.1 est non satisfait)
rhythmbox-0.11.2-2mdv2008.0.i586
(en raison du manque de libgnome-media-profiles.so.0)
sound-juicer-2.20.1-1.1mdv2008.0.i586
(en raison du manque de libgnome-media-profiles.so.0)
Supprimer 4 paquetages ? (o/N)
Note que gnome-session n'est pas impacté par la suppression de gnome-media.
> 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.
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...
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.
> 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 libnm
libnm_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.
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.
> 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.
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 nm
libnm-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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
> 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 wpasupplicant
le 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...
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).
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.
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.
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.
"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.
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 ^^^)
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
> 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!
> 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.
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 !
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é.
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 ?
> 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...
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).
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.
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.
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")
> 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.
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...
> 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.
> 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)
> 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.
J'utilise régulièrement Fedora, et franchement Pirut, c'est ce
qui m'a motivé d'apprendre la syntaxe de yum.
Franchement, parfois, on clic pour activer une section, ce n'est
pris en compte parfois que 1 minute après !
Du coup, même quelqu'un d'aussi talentueux et agile que moi
avec la souris a déjà fait des bêtises. :)
On choisit un groupe ou logiciel, il se passe rien, on attend... longtemps
on ressaie de clicker, on essaie de clicker autre par, et finalement
le premier click est pris en compte mais pas le deuxième, etc...
On ne peut pas voir les pacages quand on est sans internet...
Il faut, comme le dit le monsieur, désactiver les dépôt.
Quand Pirut fonctionne, ça fenêtre ne se dessine plus...
On ne sais pas si ça a planté ou pas, on sais pas...
Bref, il faut accepter les critiques, c'est pas la mort.
Fedora, c'est super, c'est dans le haut du panier des Linux
Power-User-Friendly (!), mais comme toute chose, ça pourrait
être mieux.
Ensuite je me mets en tête de tester frysk et systemtap puisque qu'apparemment c'est installé: impossible de mettre la main dessus. Rien dans mon PATH, les paquets sont bien installés, je lis le man, fais un gros find /, mais impossible de trouver comment les lancer.
rpm -ql frysk
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
Heureusement que beaucoup ne font pas un journal à chaque fois qu'ils tombent sur un blog qui dit du mal sur une distribution.
Parce que si c'était un blog qui disait "j'ai installé, j'utilise, je n'ai pas de problème significatif, ça me convient", tu ne l'aurais pas mis.
Je peux trouver des blogs qui racontent que ça sucks grave avec Ubuntu ou Mandriva ou OpenSuse ou autres. On trouve ça sans problème.
Mais rassure toi, je ne fais pas les poubelles pour faire un journal.
Je me fous de savoir qui a le meilleur algo de résolution de dépendances dans tel ou tel cas, mais je me fie à mon expérience (plusieurs années de Debian / Ubuntu).
Aujourd'hui pour le boulot j'ai mis en place un serveur sous CentOS 5. Je me disais que c'était cool, j'ai du respect pour Redhat et Fedora même si je ne les utilise pas, c'était la chance de plonger dedans :)
Bon alors yum search qui DL à chaque fois la liste des paquets, super, j'adore attendre 10 secondes le résultat d'une recherche. Oui oui je sais, yum -C, n'empêche que vous ne me ferez pas admettre que le comportement de APT (update pour les infos de paquets, upgrade pour les paquets eux-même) n'est pas meilleur.
J'ai besoin du JDK 6.0 : bon il est pas dans les dépôts, faut installer le JDK du site de Sun puis un paquet de compat pour l'intégrer au système, admettons : rpm -Uvh jdk-sun-bidulechose.rpm java-compat-truc.rpm
rpm m'indique l'installation de "jdk", puis échoue sur java-compat
Oups la dernière version du jdk est 6 update 6, il faut 6 update 5 pour la compat... Bon, rpm-e jdk (bin ouais c'est le nom que rpm utilisait pour ce paquet) : rien. yum list installed | grep jdk (mort de rire le téléchargement des infos des dépôts pour me lister les paquets installés) : rien. Etc. (je doute pas qu'il y a un switch pour rpm qui fait ce que je veux, mais je trouve hallucinant que ni yum ni rpm ne reconnaissent le paquet que je vient d'installer, quand j'utilise le nom même que rpm lui donne lors de l'install).
Bon au final crado powa j'ai installé le paquet du jdk6u5 en plus, et ça marche.
M'enfin merci la tranche de rigolade...
Entendons-nous bien, j'veux pas rentrer dans la guerre RPM/DEB (je refuse d'utiliser cette blague d'aptitude qui me propose de désinstaller la moitié de mon système quand je veux virer un pauvre truc), mais RPM, non merci.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
> Bon alors yum search qui DL à chaque fois la liste des paquets
Non. Il download seulement un fichier de moins de 1 ko par dépôt pour vérifier que le dépôt n'a pas changé. S'il n'a pas changé, il ne downloade rien d'autre. Enfin, il y a un "time live" de 1800 secondes par défaut, donc il download au plus toutes les 30 minutes.
> yum list installed | grep jdk (mort de rire le téléchargement des infos des dépôts pour me lister les paquets installés)
Peut-être un bug. Il est corrigé dans F8.
> Bon, rpm-e jdk (bin ouais c'est le nom que rpm utilisait pour ce paquet) : rien.
Il y a 4000 façons de retrouver le nom d'un paquet. Par exemple fait $ rpm -q -f /path/file
> mais je trouve hallucinant que ni yum ni rpm ne reconnaissent le paquet que je vient d'installer, quand j'utilise le nom même que rpm lui donne lors de l'install).
Car il ne doit pas avoir le nom que tu crois...
> Bon au final crado powa j'ai installé le paquet du jdk6u5 en plus, et ça marche.
Ce paquet s'appelle jdk pour rpm. Donc l'autre dont tu parles ne dois pas s'appeller jdk (faire par exemple un "rpm -q -i -p fichier.rpm" pour le vérifier).
Notons que Sun parfois ne respecte pas la convention de nommage des noms de fichiers des paquets rpm.
Par exemple : rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm\n" -p xorg-x11-drv-ati-6.8.0-1.fc8.x86_64.rpm
xorg-x11-drv-ati-6.8.0-1.fc8.x86_64.rpm
$
Il me redonne le nom du paquet.
Pour jdk de Sun : rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm\n" -p jdk-6u6-linux-amd64.rpm
jdk-1.6.0_06-fcs.x86_64.rpm
Ben ce n'est pas le cas.
> mais RPM, non merci.
Ce n'est pas de la faute à Rpm si Sun fait n'importe quoi.
Quand tu dis RPM non merci et que tu critiques en fait yum, tu mets dans le même bateau Mandriva, OpenSUSE et Fedora/Red Hat.
Aucune de tes critiques n'est valable avec Urpmi/Mandriva qui utilise pourtant bien RPM. Donc, stop : critique yum, mais pas RPM dans ces cas.
# Un énorme troll
Posté par Jean-François Martin . Évalué à 1.
[^] # Re: Un énorme troll
Posté par tuXico . Évalué à 4.
En fait, en ayant lu Ton commentaire, j'avais peu envie de lire le lien mais il est très constructif. Il souligne des problèmes que Fedora a tout intérêt à résoudre.
[^] # Re: Un énorme troll
Posté par libre Cuauhtémoc . Évalué à 2.
[^] # Re: Un énorme troll
Posté par tuXico . Évalué à 7.
Mais (si je ne me trompe pas) le système de paquets a été revu récemment (?) et donc forcément, il faut laisser du temps pour améliorer les choses (et signaler les fonctionnements qui *paraissent* mauvais).
Il me semble que les interfaces graphiques sous debian (qui sont loin d'êtres exemptes de soucis) émettent un warning si Ta déselection entraîne des modifs pour d'autres paquets (genre "attention si Tu fais vraiment ça, ça va faire ça, Tu veux vraiment ou Tu faisais une feinte ?" et perso, je préfère cette approche plutôt que "hey, j'ai fait comme Tu m'as dit mais du coup, j'ai aussi du aussi faire ça", la différence étant que Ta liste de paquets sélectionnés à l'install/update/desinstall/... a été modifiée dans le second cas et que Tu dois la rechecker pour être sûr que c'est dans l'état voulu...)
En même temps, je reprenais les propos de quelqu'un d'autre sur le wwwoueb et je n'ai apparemment pas sû bien mettre en avant que je ne reprenais rien à mon compte : j'ai rien testé, comment pourrais-je critiquer ? Par contre, la première réponse me paraissait un poil partisane : "mais si ça marche et si ça marche pas, c'est sa faute"
[^] # Re: Un énorme troll
Posté par Anonyme . Évalué à 7.
apt installé fraichement je lui demande de desinstaller 3 glibc. et la gros message enorme et il me demande d'ecrire: Yes, i want to do that
y ne marche pas yes non plus, il fallait respecter la casse et bien ecrire toute la phrase. impressionnant
[^] # Re: Un énorme troll
Posté par ß ß . Évalué à 2.
Le message exact est :
You are about to do something potentially harmful.To continue type in the phrase "Yes, do as I say!"
Vous êtes sur le point de faire quelque chose de potentiellement dangereuxPour continuer, tapez la phrase "Oui, faites ce que je vous dis !"
Et il faut effectivement taper toutes les lettres, point d'exclamation y compris (oui, même pour les malheureux administrateurs de debian de l'hexagone avec un clavier français et une locale en ou C.
[^] # Re: Un énorme troll
Posté par IsNotGood . Évalué à 2.
Il y a retour à l'utilisateur avec un message qui indique explicitement que des paquets vont être supprimer (c'est indiqué deux fois).
L'action est faite que lorsque l'utilisateur a cliqué sur "continué" de la boite qui affiche la liste des paquets qui vont être supprimé (et il est clairement indiqué qu'ils vont être supprimé).
> Il souligne des problèmes que Fedora a tout intérêt à résoudre.
Personne ne sait résoudre le problème entre la machine et la chaise.
[^] # Re: Un énorme troll
Posté par tuXico . Évalué à 1.
De là à dire que c'est ce type le problème, il y a un pas que je Te laisse faire sans moi.
[^] # Re: Un énorme troll
Posté par IsNotGood . Évalué à 5.
Très juste. La distribution est au service de l'utilisateur et donc doit être adaptée à l'utilisateur. Il y a peut-être un problème d'ergonomie, de retour d'information, de contrôle que l'utilisateur ne fait pas n'importe quoi, etc dans Pirut. Mais ce n'est pas pour autant qu'il faut en conclure que pirut, yum et rpm puent. Surtout qu'il y a eu demande de confirmation avant que l'utilisateur fasse sa connerie.
Que dit l'utilisateur après sa conneries (qu'on peut comprendre) ?
- "Seulement les dépendances et RPM, même 10 ans après, ça ressemble toujours à de l'escroquerie."
C'est un fort de café alors que Pirut/yum/rpm a seulement fait son boulot. Peut-être avec "trop de zèle", mais avec la "bénédiction" de l'utilisateur.
[^] # Re: Un énorme troll
Posté par tuXico . Évalué à 2.
Mon voisin a une ubuntu qu'il casse cycliquement et donc cycliquement je fais fasse à de nouveaux (et vieux aussi) problèmes.
Je ne lui hurle pas (trop) après, par contre, le jour où la distrib incluera plus de garde fous (ou le jour où il appréhendera mieux ce qu'il fait), j'aurai plus de temps pour jouer au djumbé avec lui... (Par contre, effectivement, il ne me sort jamais du "linux, c'est vraiment trop de la merde")
# Re:
Posté par IsNotGood . Évalué à 5.
Fedora vient de perdre un utilisateur qui clique partout sans réfléchir et ne lit pas les avertissements.
Tirons quelques enseignements.
Enseignement technique ; supprimer Gnome alors qu'on est sous Gnome, n'est pas une bonne idée.
Notons que frysk est présent.
yum install frysk...
frysk x86_64 0.2.1-0.fc8 updates
Il y a une mise à jours mais c'est aussi dans la release :
yum install --disablerepo=updates frysk...
frysk x86_64 0.0.1.2007.10.17-1.fc8 fedora
Yum search le trouve :
yum search frysk...
frysk.x86_64 : Frysk execution analysis and debugging tools
frysk-gnome.x86_64 : The GNOME front-end of Frysk
frysk.x86_64 : Frysk execution analysis and debugging tools
frysk-gnome.x86_64 : The GNOME front-end of Frysk
frysk-devel.x86_64 : The development part of Frysk
frysk-devel.i386 : The development part of Frysk
frysk-devel.x86_64 : The development part of Frysk
frysk-devel.i386 : The development part of Frysk
Ben oui, il faut installer frysk-gnome pour avoir un truc dans $PATH.
Systemtap est aussi présent, pas de problème.
je désélectionne aussi "Bureautique/Productivité" (sic) qui selon sa description doit contenir des afficheurs PDF, etc.
Erreur monumentale.
Faisons avec yum, pirut fait la même chose (sauf qu'il y les traductions des noms de groupe) :
yum groupremove "Office/Productivity"...
Removing:
dia x86_64 1:0.96.1-6.fc8 installed 15 M
evince x86_64 2.20.2-1.fc8 installed 3.3 M
openoffice.org-calc x86_64 1:2.3.0-6.11.fc8 installed 21 M
openoffice.org-draw x86_64 1:2.3.0-6.11.fc8 installed 2.9 M
openoffice.org-graphicfilter x86_64 1:2.3.0-6.11.fc8 installed 437 k
openoffice.org-impress x86_64 1:2.3.0-6.11.fc8 installed 4.9 M
openoffice.org-langpack-en x86_64 1:2.3.0-6.11.fc8 installed 21 M
openoffice.org-math x86_64 1:2.3.0-6.11.fc8 installed 3.5 M
openoffice.org-writer x86_64 1:2.3.0-6.11.fc8 installed 7.4 M
openoffice.org-xsltfilter x86_64 1:2.3.0-6.11.fc8 installed 257 k
Je répète, pirut fait la même chose.
Par contre un "yum groupremove 'GNOME Desktop Environment'", c'est une autre histoire, puisque sur mon système (léger), il vire 129 paquets.
Ensuite, il n'y pas de gestion de dépendances entre les méta-paquets
Ben oui il a gestion de dépendance. Si tu demandes à supprimer Gnome et qu'il y a, par exemple, des -devel Gnome (qui ne sont pas référencé par "GNOME Desktop Environment'"), ben il va les virer.
Et ça ne sont pas des méta-paquets, mais des groupes (un groupe de paquet). Il n'y a pas de dépendance codée entre groupe, mais ce n'est pas grave car il y a les dépendances entre paquets.
ça a un peu déselectionner par hasard "Environnement de bureau GNOME", sans me le dire bien sur...
Information utile : Tu n'es pas sous Windows.
Ça n'a pas désélectionner "Environnement de bureau GNOME" car pirut ne le fait que sur demande de l'utilisateur. Par contre via les dépendances rpm ça peut effectivement virer une bonne partie de "Environnement de bureau GNOME".
je lance ce gestionnaire de paquets graphique, il n'arrive logiquement pas à récupérer la liste des paquets: il y a bien un bouton "Annuler" mais il ne fonctionne pas.
Apparament il mache très bien. Tu cliques sur "Annuler" et il ne fait rien. Bref, le bouton porte bien son nom. Pour quitter l'appli, il faut fermer la fenêtre ou faire menu : "Fichier"->"Quitter".
Et là je vois l'installateur de paquets afficher des mise à jour (???)
Je n'y crois pas.
Voila ce qu'affiche Pirut :
Sélections de paquetages
Vous avez choisi d'installer ou supprimer les logiciels suivants.
Détails :
Suppression de :
...
Magnifique: en quelques minutes, 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. J'insiste, je n'ai pas fait n'importe quoi.
T'as demandé la suppression de paquets, cette demande via les dépendances supprimer d'autres paquets.
Seulement les dépendances et RPM, même 10 ans après, ça ressemble toujours à de l'escroquerie.
En fait, tu viens de passer à un système qui gère très bien les dépendances. Mais manifestement tu n'es pas habitué.
Je pense qu'on peut considéré qu'il y a un problème pour ton cas. Pas un problème technique (rpm gère très bien les dépendances) mais de définition des groupes. Virer groupe "Sons et vidéos" vire gnome-media, qui vire gnome-volume-manager, qui vire gnome-session.
La gestion des dépendances est nickel, mais le résultat surprenant.
Oublions le reste.
Le plus intéressant, c'est que ça vient d'un utilisateur Debian. Combien d'heures il a passé sur la doc Debian ? Combien de centaines de page de doc il a lu ? Des tonnes. Mais pour Fedora il est hors de question qu'il lise une "popup".
Sûr que lorsqu'il a un comportement non prévu avec apt, il doit réfléchir pour savoir ce qu'il se passe. Mais avec Fedora il nous tombe de suite un "Seulement les dépendances et RPM, même 10 ans après, ça ressemble toujours à de l'escroquerie" en 2 secondes et sans réfléchir.
Conclusion :
Si vous ne voulez pas Fedora, n'installez pas Fedora.
PS: Il y a apt et synaptic sous Fedora. Sûr qu'avec ses derniers il va trouver la gestion des dépendances nickels...
Mais, au moins pour les suppressions, c'est rpm qui les calcules, ou au moins les impose.
[^] # Re: Re:
Posté par Pipo Le Clown . Évalué à 6.
gniii? Quand je vire une couche supérieure, il vire toutes les couches inférieures ?
Trois possibilités:
- J'ai mal compris
- Tu te trompes (j'espere que c'est une de ses deux la)
- RPM reste un truc tout pourri pour gérer les dépendances.
Pour moi, un gestionnaire de paquets doit faire:
- Si j'installe quelque chose, il installe tous les paquets nécessaires.
- Si je vire quelque chose, il vire tous les paquets qui ont _besoin_ de ce que je vire. A ma connaissance gnome-session n'a pas _besoin_ de gnome-volume-manager...
[^] # Re: Re:
Posté par Pipo Le Clown . Évalué à 8.
Le gagnant est donc (roulement de tambour....)
RPM (yum en fait mais bon) reste un truc tout pourri pour gérer les dépendances.
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é.
Yeah!!
[^] # Re: Re:
Posté par Jeanuel (site web personnel) . Évalué à 7.
C'est pas possible une mauvaise foi pareille. Le commentaire plus bas, que tu sites, il dit texto : "Y'a PAS de problème avec RPM, c'est YUM qui merde". Et tu traduis par "C'est RPM qui est pouris" ! Ca c'est du troll de grande classe.
[^] # Re: Re:
Posté par IsNotGood . Évalué à -3.
Yum ne merde pas.
[^] # Re: Re:
Posté par Gniarf . Évalué à 8.
[^] # Re: Re:
Posté par briaeros007 . Évalué à 6.
Tu fais les questions et les réponses maintenant ?(avec réponse partisane donc troll detected)
[^] # Re: Re:
Posté par tuXico . Évalué à 3.
Il y a deux ans, un bon admin a testé Ubuntu, n'a pas réussi à configurer le wifi avec son clicodrome... Donc, il ne fait pas plus d'effort et gueule partout que "Ubuntu, c'est pourri".
Et bien, effectivement, ça me fait bien chier de voir un gars à priori fort en Unix, ne pas être capable de faire un poil d'effort pour trouver le pb et hurler des choses sans fondement (en l'occurence, c'était un pb utilisateur -la fameuse chaise si chère à IsNotGood- et pas un problème de distrib. Quand bien même, la personne dont je parle avait largement le niveau pour savoir si ça venait de l'appli utilisée et donc plutôt blamer gnome ou si ça venait d'autre part)
Effectivement, surtout au niveau des distribs grand public, on a un problème de syndrôme windowsien ("je veux que ça marche out of the box") même de la part de personne qui à priori devrait mieux identifier les problèmes...
C'est dommage et dommageable.
[^] # Re: Re:
Posté par briaeros007 . Évalué à 10.
Perso, quand j'ai testé ubuntu j'ai fait ça.
Je me suis dit "je ne vais pas profiter de mon exp sous linux pour faire quelque chose, je vais me mettre à la place de quelqu'un qui n'y connais rien"... Ben je suis finalement resté sur ma debian XD.
[^] # Re: Re:
Posté par tuXico . Évalué à 7.
j'ai testé ubuntu
Ben je suis finalement resté sur ma debian
J'ai fait pareil.
[^] # Re: Re:
Posté par ploum (site web personnel, Mastodon) . Évalué à 5.
Après, ce n'est pas toujours possible car :
- les utilisateurs attendent des choses différentes donc forcément, concevoir un système pour plusieurs utilisateurs, c'est trouver un juste milieu.
- le système est lié par des contraintes techniques/sécurité. L'ordinateur ne sait pas encore lire dans notre esprit, il faut apprendre à utiliser un clavier et une souris.
Mais en dehors de ces 2 points, je le dis et le répète : si l'utilisateur n'y arrive pas, c'est un bug. A fortiori si tous les utilisateurs n'y arrivent pas. Mais c'est sûr que c'est plus facile de se réfugier derrière le "Ils sont tous bêtes" (et je suis leur chef)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Re:
Posté par tuXico . Évalué à 3.
Dans les deux cas, l'utilisateur est fort techniquement (mais veut se comporter en user lambda - ce n'est pas un soucis), le premier dit les choses un peu agressivement mais de manière constructive, le second n'a aucune constructivité et décridibilise une distrib (si ce n'est linux au sens très large : le vrai utilisateur lambda fait peu de différence entre Ubuntu, Fedora, kernel, logiciel libre ou même les *BSD et confond le tout allègrement).
Tu vois ce que je reproche (sans élitisme, vraiment) ?
[^] # Re: Re:
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
Sur la forme, je trouve que c'est un vulgaire troll et ça me rassure de voir qu'on en revient à un bon vieux APT vs RPM :-)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Re:
Posté par Dr BG (site web personnel) . Évalué à 6.
Ce troll montre surtout l'ignorance de ceux qui crachent sur RPM : il ne s'agit pas franchement de la même chose, RPM est plutôt au niveau des .deb (format) et de dpkg ! Beaucoup de choses qui sont reprochés à RPM par ceux qui n'y connaissent rien vient souvent de problèmes : 1) d'empaquetage, les dépendances sont mal listées, 2) de gestion des dépendances par urpmi/yum/yast/ etc.
Amis de linuxfr, si vous voulez faire du troll de qualité, cessez de tout confondre et de dire n'importe quoi sur RPM (d'ailleurs les gens qui en parlent n'ont souvent pas approché un RPM depuis le Mandrake 9.0)
[^] # Re: Re:
Posté par Pipo Le Clown . Évalué à 3.
C'est pas faux (au moins dans mon cas). Mais pourquoi changer quand on est satisfait de ce qu'on a (et que c'est le mieux de toutes façons) ?
Sinon, juste pour savoir, tu a réussi à le faire fonctionner ton media center Mandriva ? J'ai des CD d'install Debian si tu veux.... :P
[^] # Re: Re:
Posté par lezardbreton . Évalué à 2.
urpmi elisa : c'est fini...
[^] # Re: Re:
Posté par Pipo Le Clown . Évalué à 1.
[^] # Re: Re:
Posté par lezardbreton . Évalué à 1.
Si encore tu m'avais dit que c'était la configuration de la télécommande, je comprends, c'est toujours galère.
[^] # Re: Re:
Posté par Dr BG (site web personnel) . Évalué à 3.
Pour ceux qui répondent à l'ami Pipo, vous devez savoir que c'est une remarque perso ;-)
[^] # Re: Re:
Posté par gnumdk (site web personnel) . Évalué à 10.
>qui vire gnome-session.
$ apt-get remove gnome-media
Les paquets suivants seront ENLEVÉS :
gnome-media
Hmm, marche très bien sous Debian... Yum Suxor ? ;)
[^] # Re: Re:
Posté par IsNotGood . Évalué à 5.
Rien à voir, Yum et rpm marchent très bien.
Gnome-volume-manager a "Requires: gnome-media". C'est un choix du développeur (c'est peut-être aussi une nécessité, je n'en sais rien).
Gnome-session a "Requires: gnome-volume-manager". C'est un choix du développeur (c'est peut-être aussi une nécessité, je n'en sais rien).
Donc lorsque gnome-media est viré, gnome-session est viré aussi. Yum, pirut ou rpm font parfaitement leur boulot. Et PackageKit ferait la même chose. Et apt (qui existe sous Fedora) ferait aussi exactement la même chose.
Par contre, on peut se demander qui les "Requires: gnome-media" ou "gnome-volume-manager" sont vraiment nécessaires. Il faudrait le demander au développeur.
[^] # Re: Re:
Posté par liberforce (site web personnel) . Évalué à 9.
Sous Mandriva Linux 2008.1:
[root@alcor trunk]# urpme --test gnome-media
Pour satisfaire les dépendances, les 4 paquetages suivants vont être désinstallés (20Mo):
gnome-media-2.20.1-1mdv2008.0.i586
(en raison du manque de libcddb-slave2.so.0,
en raison du manque de libgnome-media-profiles.so.0)
libcddb-slave2_0-2.20.1-1mdv2008.0.i586
(car gnome-media >= 2.20.1 est non satisfait)
rhythmbox-0.11.2-2mdv2008.0.i586
(en raison du manque de libgnome-media-profiles.so.0)
sound-juicer-2.20.1-1.1mdv2008.0.i586
(en raison du manque de libgnome-media-profiles.so.0)
Supprimer 4 paquetages ? (o/N)
Note que gnome-session n'est pas impacté par la suppression de gnome-media.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
Oui. J'ai dit développeur, mais ça sous entendait packager si ce n'est pas la même personne.
# Yum remove considered harmful
Posté par GeneralZod . Évalué à 9.
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
Posté par Nicolas Noirbent . Évalué à 10.
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
Posté par GeneralZod . Évalué à 3.
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
Posté par IsNotGood . Évalué à 3.
Ben tu le retrouveras dans PackageKit et apt et tous les autres.
[^] # Re: Yum remove considered harmful
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 10.
Sauf que chez Debian on sait faire des paquets correctement...
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . Évalué à 2.
[^] # Re: Yum remove considered harmful
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 1.
Ceci dit, je suis tres honore d'apprendre que ma parole represente toute l'organisation Debian...
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . Évalué à 1.
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
Posté par imalip . Évalué à 9.
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . Évalué à 1.
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
Posté par imalip . Évalué à 5.
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.
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . Évalué à 2.
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
Posté par imalip . Évalué à 3.
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.
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . Évalué à 1.
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
Posté par gnumdk (site web personnel) . Évalué à 2.
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:~$
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . Évalué à 3.
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
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 0.
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
Posté par IsNotGood . Évalué à 2.
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
Posté par IsNotGood . Évalué à 2.
Mais n'utilise pas Fedora ni Debian.
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . Évalué à 2.
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
Posté par imalip . Évalué à 3.
Demande "network management framework (GLib shared library)"
[^] # Re: Yum remove considered harmful
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
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
Posté par IsNotGood . Évalué à 2.
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
Posté par ruz revr . Évalué à 0.
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . Évalué à 2.
[^] # Re: Yum remove considered harmful
Posté par ruz revr . Évalué à 1.
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . Évalué à 2.
Ceci dit, ça va peut-être changer pour F9 et je ne sais pas ce qu'il en est.
[^] # Re: Yum remove considered harmful
Posté par gnumdk (site web personnel) . Évalué à 1.
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.
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . Évalué à 1.
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
Posté par Nicolas Noirbent . Évalué à 9.
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
Posté par IsNotGood . Évalué à 2.
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
Posté par Psychofox (Mastodon) . Évalué à 3.
[^] # Re: Yum remove considered harmful
Posté par Psychofox (Mastodon) . Évalué à 2.
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
Posté par IsNotGood . Évalué à 2.
[^] # Re: Yum remove considered harmful
Posté par tiot (site web personnel) . Évalué à 2.
À 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.
[^] # Re: Yum remove considered harmful
Posté par Nicolas Noirbent . Évalué à 2.
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
Posté par brunus (site web personnel) . Évalué à 4.
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
Posté par GeneralZod . Évalué à 5.
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
Posté par brunus (site web personnel) . Évalué à 3.
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
Posté par IsNotGood . Évalué à 2.
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
Posté par IsNotGood . Évalué à 3.
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
Posté par GeneralZod . Évalué à 2.
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
Posté par liberforce (site web personnel) . Évalué à 2.
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
Posté par IsNotGood . Évalué à 2.
# 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
Posté par Nicolas Noirbent . Évalué à 5.
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
Posté par IsNotGood . Évalué à 2.
[^] # Re: Yum remove considered harmful
Posté par Nicolas Noirbent . Évalué à 4.
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . Évalué à 2.
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
Posté par gnumdk (site web personnel) . Évalué à 3.
- gnome-applets
- totem
- gnome-media
J'appelle pas ce tout gnome...
[^] # Re: Yum remove considered harmful
Posté par Psychofox (Mastodon) . Évalué à 7.
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
Posté par IsNotGood . Évalué à 2.
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
Posté par tiot (site web personnel) . Évalué à 3.
(ok ok il y a beaucoup moins de paquet)
[^] # Re: Yum remove considered harmful
Posté par Moonz . Évalué à 4.
Sous Debian, il y a un joli champ Recommends:, qui fait parfaitement l'affaire pour des trucs comme ça
[^] # Re: Yum remove considered harmful
Posté par tuXico . Évalué à 2.
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")
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . Évalué à 2.
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
Posté par Christophe Merlet (site web personnel) . Évalué à 1.
[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
Posté par IsNotGood . Évalué à 2.
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
Posté par GeneralZod . Évalué à 2.
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
Posté par IsNotGood . Évalué à 2.
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.
# Il dit pas que des conneries.
Posté par kowalsky . Évalué à 10.
qui m'a motivé d'apprendre la syntaxe de yum.
Franchement, parfois, on clic pour activer une section, ce n'est
pris en compte parfois que 1 minute après !
Du coup, même quelqu'un d'aussi talentueux et agile que moi
avec la souris a déjà fait des bêtises. :)
On choisit un groupe ou logiciel, il se passe rien, on attend... longtemps
on ressaie de clicker, on essaie de clicker autre par, et finalement
le premier click est pris en compte mais pas le deuxième, etc...
On ne peut pas voir les pacages quand on est sans internet...
Il faut, comme le dit le monsieur, désactiver les dépôt.
Quand Pirut fonctionne, ça fenêtre ne se dessine plus...
On ne sais pas si ça a planté ou pas, on sais pas...
Bref, il faut accepter les critiques, c'est pas la mort.
Fedora, c'est super, c'est dans le haut du panier des Linux
Power-User-Friendly (!), mais comme toute chose, ça pourrait
être mieux.
# man rpm
Posté par Infernal Quack (site web personnel) . Évalué à 2.
Ensuite je me mets en tête de tester frysk et systemtap puisque qu'apparemment c'est installé: impossible de mettre la main dessus. Rien dans mon PATH, les paquets sont bien installés, je lis le man, fais un gros find /, mais impossible de trouver comment les lancer.
rpm -ql frysk
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: man rpm
Posté par Vivi (site web personnel) . Évalué à 2.
man frysk
qui indique autres pages man à consulter ...
[^] # Re: man rpm
Posté par kowalsky . Évalué à 1.
# Le troll a bien bouffé...
Posté par liberforce (site web personnel) . Évalué à 8.
[^] # Re: Le troll a bien bouffé...
Posté par IsNotGood . Évalué à 3.
Parce que si c'était un blog qui disait "j'ai installé, j'utilise, je n'ai pas de problème significatif, ça me convient", tu ne l'aurais pas mis.
Je peux trouver des blogs qui racontent que ça sucks grave avec Ubuntu ou Mandriva ou OpenSuse ou autres. On trouve ça sans problème.
Mais rassure toi, je ne fais pas les poubelles pour faire un journal.
[^] # Re: Le troll a bien bouffé...
Posté par liberforce (site web personnel) . Évalué à 1.
[^] # Re: Le troll a bien bouffé...
Posté par Spyhawk . Évalué à 7.
[^] # Re: Le troll a bien bouffé...
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
# RPM ? Non merci.
Posté par Sufflope (site web personnel) . Évalué à 0.
Aujourd'hui pour le boulot j'ai mis en place un serveur sous CentOS 5. Je me disais que c'était cool, j'ai du respect pour Redhat et Fedora même si je ne les utilise pas, c'était la chance de plonger dedans :)
Bon alors yum search qui DL à chaque fois la liste des paquets, super, j'adore attendre 10 secondes le résultat d'une recherche. Oui oui je sais, yum -C, n'empêche que vous ne me ferez pas admettre que le comportement de APT (update pour les infos de paquets, upgrade pour les paquets eux-même) n'est pas meilleur.
J'ai besoin du JDK 6.0 : bon il est pas dans les dépôts, faut installer le JDK du site de Sun puis un paquet de compat pour l'intégrer au système, admettons : rpm -Uvh jdk-sun-bidulechose.rpm java-compat-truc.rpm
rpm m'indique l'installation de "jdk", puis échoue sur java-compat
Oups la dernière version du jdk est 6 update 6, il faut 6 update 5 pour la compat... Bon, rpm-e jdk (bin ouais c'est le nom que rpm utilisait pour ce paquet) : rien. yum list installed | grep jdk (mort de rire le téléchargement des infos des dépôts pour me lister les paquets installés) : rien. Etc. (je doute pas qu'il y a un switch pour rpm qui fait ce que je veux, mais je trouve hallucinant que ni yum ni rpm ne reconnaissent le paquet que je vient d'installer, quand j'utilise le nom même que rpm lui donne lors de l'install).
Bon au final crado powa j'ai installé le paquet du jdk6u5 en plus, et ça marche.
M'enfin merci la tranche de rigolade...
Entendons-nous bien, j'veux pas rentrer dans la guerre RPM/DEB (je refuse d'utiliser cette blague d'aptitude qui me propose de désinstaller la moitié de mon système quand je veux virer un pauvre truc), mais RPM, non merci.
[^] # Re: RPM ? Non merci.
Posté par Infernal Quack (site web personnel) . Évalué à 0.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: RPM ? Non merci.
Posté par IsNotGood . Évalué à 3.
Non. Il download seulement un fichier de moins de 1 ko par dépôt pour vérifier que le dépôt n'a pas changé. S'il n'a pas changé, il ne downloade rien d'autre. Enfin, il y a un "time live" de 1800 secondes par défaut, donc il download au plus toutes les 30 minutes.
> yum list installed | grep jdk (mort de rire le téléchargement des infos des dépôts pour me lister les paquets installés)
Peut-être un bug. Il est corrigé dans F8.
> Bon, rpm-e jdk (bin ouais c'est le nom que rpm utilisait pour ce paquet) : rien.
Il y a 4000 façons de retrouver le nom d'un paquet. Par exemple fait
$ rpm -q -f /path/file> mais je trouve hallucinant que ni yum ni rpm ne reconnaissent le paquet que je vient d'installer, quand j'utilise le nom même que rpm lui donne lors de l'install).
Car il ne doit pas avoir le nom que tu crois...
> Bon au final crado powa j'ai installé le paquet du jdk6u5 en plus, et ça marche.
Ce paquet s'appelle jdk pour rpm. Donc l'autre dont tu parles ne dois pas s'appeller jdk (faire par exemple un "rpm -q -i -p fichier.rpm" pour le vérifier).
Notons que Sun parfois ne respecte pas la convention de nommage des noms de fichiers des paquets rpm.
Par exemple :
rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm\n" -p xorg-x11-drv-ati-6.8.0-1.fc8.x86_64.rpmxorg-x11-drv-ati-6.8.0-1.fc8.x86_64.rpm
$
Il me redonne le nom du paquet.
Pour jdk de Sun :
rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm\n" -p jdk-6u6-linux-amd64.rpmjdk-1.6.0_06-fcs.x86_64.rpm
Ben ce n'est pas le cas.
> mais RPM, non merci.
Ce n'est pas de la faute à Rpm si Sun fait n'importe quoi.
[^] # Re: RPM ? Non merci.
Posté par lezardbreton . Évalué à 6.
Aucune de tes critiques n'est valable avec Urpmi/Mandriva qui utilise pourtant bien RPM. Donc, stop : critique yum, mais pas RPM dans ces cas.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.