IsNotGood a écrit 5009 commentaires

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.

> 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...

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.

> 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.

Si la librairie n'est pas utilisée...

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.

> C'est surement une dépendence indirecte

Oui. Et quand on fait "yum remove ..." il vérifie les dépendance indirecte.

Je serait curieux de savoir si quelqu'un a liferea > 1.4 sous Debian et sans libnm-util. Pour sid, ça m'étonnerait que ça soit possible.

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.

> En l'occurence liferea n'utilise aucun symbole directement de libnm-utils.

Liferea de F8 utilise libnm-utils. C'est un fait. Je ne sais pas pourquoi, mais c'est un fait. Ce n'est pas une invention de rpm ou du packager.

> Et meme si c'était le cas, cette lib est *aussi* un package séparé, on peut toujours virer NM.

Cool.

> 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.

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.

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.

Mais oui.
La liaison avec libnm-util.so.0 elle vient d'où à ton avis ? De rpm ?
Ben non, elle vient de ld.

> Debian séparent les lib des programmes réels.

Excellente idée. Fedora fait de même :
# # rpm -q --provides NetworkManager-glib
libnm_glib.so.0()(64bit)
libnm_glib_vpn.so.0()(64bit)
NetworkManager-glib = 1:0.7.0-0.6.7.svn3235.fc8

Fait "apt-get|urpmi|etc remove alsa-lib" et tu verras d'autres exemple "cocasses".

> 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.

> 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.

> 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...

Super. Un bug (peut-être, car la dépendance n'est peut-être pas la pour rien) est découvert dans Fedora, et Debian fait le coq.

> Il faudrait demander au packager plutôt qu'au développeur...

Oui. J'ai dit développeur, mais ça sous entendait packager si ce n'est pas la même personne.

> YUM qui merde

Yum ne merde pas.

> http://forums.fedora-fr.org/search.php?search_id=232036840&a(...)

Votre recherche n'a renvoyé aucun résultat.


> Tu as 3 raisons pour laquelle yum remove fout le bordel

Pourquoi tu fais ce que tu reproches aux autres ?
Ce n'est pas "yum remove" le problème car le problème tu l'as avec rpm ou pirut ou apt ou PackageKit ou n'importe quoi.

Notre ami Benoît Dejean voit le groupe "Sound and Video" et n'en veut pas. Donc il demande sa suppression. Après que Pirut lui informe des conséquences (liste des paquets qui vont être supprimés), il confirme son action.
En quoi Yum ou Pirut ou Rpm ou que sais-je fout le bordel ?
C'est l'utilisateur qui a foutu le bordel.
Il aurait pû voir gnome-media et se dire qu'il n'en veut pas et faire un "yum remove gnome-media" ou "apt-get remove gnome-media" ou "PackageKit remove gnome-media", s'il ne prête pas attention à ce qu'il fait (comme lorsqu'il a utiliser Pirut), il va à la catastrophe.
Je répète encore, mais yum n'a rien à voir ici. C'est seulement un outil qui fait bien son boulot même quand on lui demande une connerie. Et c'est idem pour les autres gestionnaires de paquet.

Imaginons que tu n'utilises pas sed. Tu vois sed dans PackageKit et demande de le virer. Tu ne regardes pas les conséquences et confirme. Ben t'as une méga catastrophe. J'ai pris sed, mais tu peux prendre un autre paquet obscure que tu ne connais pas.

Tu déplaces un problème de packaging pour diaboliser bêtement yum (ou pirut) alors que c'est exactement le même "problème" avec d'autres gestionnaires de paquet. Tu fais comme les gus qui disent que rpm ne sait pas gérer les dépendances car ils ont ajouter 50 000 dépôts plus incompatibles les uns que les autres et fait des "rpm --force" à la pelle.

Ne descend pas aussi bas !

Je veux bien reconnaitre un problème de dépendance en trop. Est-il normal que gnome-volume-manager dépende de gnome-media (à la demande du développeur) ? J'en sais rien, mais la question est pertinante.
Est-il normal que lorsqu'on demande de supprimer 2 paquets avec Pirut il en supprime 50 sans mettre un BIG FAT WARNING ? Effectivement, ce n'est peut-être pas normal. Mais on est alors sur un problème d'ergonomie, d'assistance à l'utilisateur, etc et plus du tout dans le registre "yum a un comportement INACCEPTABLE" (alors que yum fait exactement comme les autres...).

> * des paquets trop monolithiques

Tu mélange encore, c'est un problème de dépendance.

> du genre NetworkManager

Ici :
# yum remove NetworkManager
...
=============================================================================
Package Arch Version Repository Size
=============================================================================
Removing:
NetworkManager x86_64 1:0.7.0-0.6.7.svn3235.fc8 installed 2.3 M
Removing for dependencies:
NetworkManager-glib x86_64 1:0.7.0-0.6.7.svn3235.fc8 installed 106 k
libpurple x86_64 2.4.1-1.fc8 installed 20 M
liferea x86_64 1.4.13-2.fc8 installed 2.2 M
pidgin x86_64 2.4.1-1.fc8 installed 2.3 M


liferea et pidgin utilise libnm-util.so de NetworkManager. Donc ce n'est pas un problème du gestionnaire de paquet qui fait correctement son boulot. Sans NetworkManager, liferea ne marche plus.
Ce qui faut est que ces derniers chargent libnm-util.so à la demande. Ce n'est pas yum/pirut/dpkg/apt/etc qui peut gérer ça.

> Alsa-lib

Si tu veux tout coder en utilisant des modules, n'hésite pas. Mais je te préviens, c'est un boulot gigantesque. Pense qu'il n'y a pas que alsa-lib...

> ==> aux packagers de corriger si possible (ce qui n'est pas toujours le cas)

Les packagers corrigent si c'est un bug manisfeste. Tu fais quoi ici ? Décourager les gens à faire des rapports de bug ?
La rapport de bug pour dépendance superflux sont très très appréciées.

> * PEBCAK: certains paquets ne doivent pas être désinstallé

Et pourquoi ?


> * des coins obscurs ou le résolveur de dépendances de yum s*cks. C'est rare mais ça arrive.

Arrêtes de faire dans le FUD. Source tes info, donne des preuves, donne des exemples, donne un rapport de bug.
Arrêtes de faire dans le FUD !

> Je me suis extrêmement mal exprimé, mais ce qui s*cks, c'est que yum permet à l'utilisateur de flinguer trop facilement son système.

Les autres gestionnaires de paquet aussi. Donc dis que tous les gestionnaires de paquet sucks et arrête de t'en prendre exclusivement à yum ou pirut.
Je sais que tu n'aimes pas pirut. Mais ce n'est pas une raison pour dire des conneries.

> Dans mon explication simpliste, j'aurais du rajouter "dans certains cas, il arrive que yum ".

Dans ce cas tu aurais dû dire "dans certains cas, il arrive que yum, rpm, pirut, packagekit, dpkg, apt, smart, urpmi, etc".
Mais tu ne t'en prends mistérieusement qu'à yum/pirut...

> Supprimer le groupe "son et vidéo" ne doit pas emporter avec lui le bureau tout entier !

On peut considérer que c'est un bug. Mais ce bug n'est pas dans Pirut ou yum, c'est (peut-être) une erreur de packaging comme il en existe nombre et dans toutes les distributions !
Rien de spécifique à yum ou pirut.

> les utilisateurs font trop souvent des yum remove sans même jeter un coup d'oeil sur ce qui va être supprimé.

Et je ne vois pas en quoi PackageKit ou un autre est une réponse à ce problème entre la machine et la chaise.


J'aime beaucoup te lire ici. Mais encore une fois tu t'en prends à Yum et Pirut de façon totalement creuse. Tu fais comme les gus qui disent "rpm sucks" et se refusent à toute réfléxion car ils ont une opportunité de dire "rpm sucks". Toi c'est pareil.

> c'est un problème de packaging

Ben tu le retrouveras dans PackageKit et apt et tous les autres.

> 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.

> yum a un (très) gros problème dans la gestion des dépendances au moment de supprimer un paquet.

Tu peux sourcer ?

> Si je supprime A, je m'attends à ce que yum conserve C, mais là yum a un comportement stupide. A et C ayant été installé ensemble, yum va supprimer A, puis C et logiquement B puisque C va être supprimé.

Tu inventes ou quoi ?
Certes il y a du FUD sur rpm. Mais ajoute pas du FUD sur yum. Ou alors source.


[root@one SRPMS]# yum install fuse-smb
...
Package Arch Version Repository Size
Installing:
fuse-smb x86_64 0.8.7-1.fc8 updates 43 k
Installing for dependencies:
fuse-libs x86_64 2.7.3-2.fc8 updates 70 k
...
Installed: fuse-smb.x86_64 0:0.8.7-1.fc8
Dependency Installed: fuse-libs.x86_64 0:2.7.3-2.fc8
Complete!
[root@one SRPMS]# yum install fuse-s3fs
Package Arch Version Repository Size
Installing:
fuse-s3fs noarch 0.4-9.fc8 updates 23 k
Installing for dependencies:
fuse-python x86_64 0.2-5.fc8 fedora 76 k
...
Installed: fuse-s3fs.noarch 0:0.4-9.fc8
Dependency Installed: fuse-python.x86_64 0:0.2-5.fc8
Complete!
[root@one SRPMS]# yum remove fuse-smb
...
Package Arch Version Repository Size
Removing:
fuse-smb x86_64 0.8.7-1.fc8 installed 98 k
...
Removed: fuse-smb.x86_64 0:0.8.7-1.fc8
Complete!

Tu m'expliques ?

Ça ne fait pas ce que tu dis.

> 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.