Savoir de quel package vient un fichier...

mathieu -  
kmf31 Messages postés 1564 Statut Contributeur -
bonjour,

Comment faire pour savoir la provenace d'un fichier lorsuqu'un message de ce type s'affiche:
rpm -ivh libstdc++6-3.4.3-7mdk.ppc.rpm
erreur: Dépendances requises:
libgcc_s_nof.so.1 est nécessaire pour libstdc++6-3.4.3-7mdk
existe t il une commande qui permette de savoir de quel paquetage vient le fichier libgcc_s_nof.so.1?
on ma suggéré celle-ci:
rpm -q --whatprovides libgcc_s_nof.so.1. est elle vraiment efficace?
rxiste t il d'autres moyens de connaitre la provenance d'un fichier?

merci!!!

mathieu

5 réponses

  1. kmf31 Messages postés 1564 Statut Contributeur 501
     
    Pour un paquet deja installe:
    rpm -q -f /chemin_absolu/fichier

    fournit le nom du paquet dont ca depend. Apres tu peux ajouter l'option "-i" ou "-l" pour avoir plus d'info sur le paquet.

    Pour un paquet pas encore installe mais disponible sur le cd ou dd comme fichier:
    rpm -q -p fichier_paquet.rpm -l

    pour afficher tous les fichers la dedans. Apres tu peux y ajouter a la fin de ca:
    | grep ficher_a_chercher

    pour voir facilement si ton fichier est dans la liste.

    Sinon pour trouver le paquet il faut un peu chercher mais dans ton cas, c'est evident qu'il faut regarder cote tous les paquets gcc...
    2
  2. saga9 Messages postés 5912 Date d'inscription   Statut Contributeur Dernière intervention   876
     
    Salut
    utilises tu un Macintosh?
    Si c'est pas le cas et bien tu t'es trompé de paquetages.
    En effet, le "ppc" dans "libstdc++6-3.4.3-7mdk.ppc.rpm" indique que ce paquetage est destiné pour Mandriva pour Macintosh.

    Sinon pour repondre à ta question vas sur rpmfind.net qui est un moteur de recherche pour rpm.
    L'avantage est qu'il te trouve les paquetages pour chaque distribution. Il te fournit pour chaque paquetage (=une ligne) un premier lien vers une fiche descriptif ou est listé l'ensemble des dependances requises avec un lien pour aller telecharger le paquetage correspondant à chaque dependance!!!

    1
  3. mathieu
     
    merci bcp pour les infos. je v aller voguer sur rpmfind.net.

    a +++

    mathieu
    0
  4. mathiru
     
    bonjout,

    Est il possible de savoir ce qu'un tar gz va exactelment installer: la liste des fichiers avec leur localisation.
    de pus, jaimerais savoir de quelle compilation viennent des fichiers qui se trouvent ds /usr/local/lib par exzmple ou autres répertoires?comment savoir de kel tar gz ils proviennent?

    merci!!!
    0
  5. Vous n’avez pas trouvé la réponse que vous recherchez ?

    Posez votre question
  6. kmf31 Messages postés 1564 Statut Contributeur 501
     
    Ce sont de questions subtiles qui touchent en effet l'inconvenient des paquets tar. C'est plus difficile a enlever/desinstaller!!

    D'abord avec la commande: "tar tvzf ficher.tar.gz" tu te fais afficher le contenu d'un paquet mais si ce sont des sources qu'il faut compiler (avec ./configure, make et "make install") ce n'est pas ca qui est important. Par contre pour un paquet tar.gz binaire (contentant que les fichiers tous pres pour l'installation) c'est deja tres util.

    Est il possible de savoir ce qu'un tar gz va exactelment installer: la liste des fichiers avec leur localisation.

    Il y a une facon assez simple. Tu configure pour un autre arbre que /usr/local/... en faisant ceci (sur une partition "ext3" et surtout pas une sur partition "fat"!!!):
    tar xvzf paquet.tar.gz
    mkdir arbre_test
    cd <repertoire_du_paquet>
    ./configure --prefix=../arbre_test
    make
    make install
    cd ../arbre_test
    ls -lR

    De cette facon tu as compile et installe a un endroit chez toi (on peut tout faire sans etre root si au debut on est quelques part dans son home).
    Apres dans le repertoire arbre_test tu devrais avoir de sous-repertoires bin/, lib/, peut-etre: man/, info/, share/...
    tous contenant de fichiers pour ton paquet. Tu peux aussi rediriger la liste de fichier produit par ls vers un autre fichier:
    ls -lR > liste_fichier

    Si tu est content tu peux effacer avec:
    mv liste_fichier ../
    cd ..
    rm -rf arbre_test

    et refaire "./configure" sans l'option "--prefix". Dans ce cas ca ira dans /usr/local et pour le "make install" il faudra etre root. Dans le fichier "liste_fichier" tu auras une copie des noms et endroits de tous les fichiers installe relative a l'arbre principale (normalement /usr/local/ mais au debut c'etait "arbre_test"). Plus tard tu pourras utiliser cette liste pour "nettoyer" manuellement ton paquet. Bien-entendu ce n'est pas commode!!

    A savoir pour desinstaller les fichiers dans /usr/local/...:
    souvent (mais pas toujours) la commande "make uninstall" effectuee apres un "make install" marche pour desinstaller. Pour ca il faut garder une copie du repertoire des sources.

    de pus, jaimerais savoir de quelle compilation viennent des fichiers qui se trouvent ds /usr/local/lib par exzmple ou autres répertoires?comment savoir de kel tar gz ils proviennent?

    C'est presque impossible, sauf si on sait d'avance qu'un fichier xyz apartient a un certain paquet. Le point important: Pour les tar.gz installe avec ./configure dans /usr/local/... il n'y a pas de base de donnees comme pour les "*.rpm" ou les paquets debian ("*.deb" ?). C'est exactement pour ca que Redhat a invente il y a longtemps le programme rpm qui fait une gestion plus intelligente.
    Apart ca pour certains paquet tar.gz il est possible de transformer ca vers un paquet rpm avec "rpm" et les bonnes options (genre "--build" ..., regarde "man rpm").

    Dans le Slackware il y avait (ou il y a toujours ?) un systeme de scripts base sur de tar.gz (mais de paquets binaire precompile). Ici les scripts utilisent tar et gzip pour installer mais ils gerent aussi une base de donnees de fichiers installe. A la fin ca fonctionne comme rpm sauf ca utilise un tar.gz (binaire) au lieu d'un rpm et c'est un peu moins sophistique avec les dependances etc. Il faudrait voir s'il est possible d'installer ces scripts sur une autre distribution pour gerer le /usr/local/.
    Peut-etre c'est possible mais aussi assez complique.
    0