La FAQ à Schneider

Recherche :

Dernière réponse
Sujet : La FAQ à Schneider
nicotine	parfois , l'avantage des rpms , c'est d'eviter de changer de chemise a chaque fois :D

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

nicotine

parfois , l'avantage des rpms , c'est d'eviter de changer de chemise a chaque fois :D

gfive

ben en fait, j'utilise un mix des deux, mais dans des cas précis :
* Le coup de la multi JVM, par exemple,
* Quand je veux tester une nouvelle veriosn d'un truc (dernier exemple en date : balsa 1.1.7) : je l'installe dans /usr/local/balsa1.1.7, je détarre, je compile tout bien, mais je le configure pour que make install me mette les fichiers dans /usr/local/balsa1.1.7
Ensuite, je fait un lien de /usr/local/bin/balsa vers /usr/local/balsa1.1.7/bin/balsa, et je peux le tester. Si il me plait pas, je vire le lien, je le remet vers la version précédente (qui marche), et j'efface le rep /usr/local/balsa1.1.7...Et le tour est joué!

* Justement, dans de tels cas, je veux pas que RPM sache que mon fichier existe!!

* bah, ls /usr/local...

Sinon, un dernier truc : on gagne toujours en performance à recompiler les sources.
Enfin, justement, le reproche que je fais à RPM, c'est qu'il ne fait confiance QU'A sa base de données : il ne vérifie pas que par hasard, par exemple, la librairie bonobo est installée : il vérifie que le package RPM est installé!! Donc, mêm esi tu as installé la librairie comme un grand, avec un numéro de version qui va bien et tout, ben RPM t'enverras chier...C'est dommage, je trouve...

gfive

Bah...le rapport, c'est qu'on m'a toujours dit "F*****g" au lieu de Forgotten...Mais t'as raison, ça fait un poil plus sérieux!! :D

Dark_Schneider

hum gestion des dépendances. Pour moi gestion de dépendance = dire kels fichiers sont nécessaires, dans kel packages ils sont inclus et permettre de les installer.

Alors comment désinstaller un tar.gz et tout les fichiers (surtout si il n'y a pas de make uninstall) ?
Si tu as un sys à base de rpm, comment</IFRAME> faire pour que le rpm sache que le fichier existe ?
comment faire une mise à jours d'un package avec un tar.gz en prenant en compte le fait que des fichiers on pu changer d'emplacement et des libs changer de nom (donc tu peux avoir des déchets) ?
comment savoir de manière précise ce qui est installer ? à partir d'une certaine taille et quantité de packages cela devient difficilement ingérable.
les rpm check aussi des fichiers (cf pb avec libXv.so avec vlc).
de plus j'ai dit sur un sys a base de rpm. La misité rpm/tar.gz c'est pas top surtout pour le rpm qui s'y perd un peu. Il faut alors user de --nodeps.

May the --force be with you.

[edtdd]--Message édité par Dark_Schneider--[/edtdd]

gfive

Ouais, mais bon, dans mon école, c'était 90% de mecs, alors les bonnes manières y étaient régulièrement baffouées!! :D

gfive

Bah comme je vois le lien dans qabsolument tous les posts où je passe, je suis allé la lire, cette FAQ, c'est un boulot remarquable (d'ailleurs, j'ai pas fini), mais bon, j'ai deux trois p'tites choses avec lesquellles je sui pas d'accord...
Dans la FAQ suer les RPM/tgz, on nous déconseille VIVEMENT d'installer des tar.gz (soit disant, y'a pas de vérif de dépendance, tout ça..) Bah non...D'abord, dans les scripts configure, y'a une vérification de dépendance, qui va souvent plus loin que celle des RPM : la vérif de dépendance de RPM vérifie la présence des packages, et pas leur intégrité..Alors que les scripts configure testent le fonctionnement des librairies et programmes mis en jeu.
De plus, un GROS avantage des tar.gz, c'est qu'ils permettent de faire cohabiter plusieurs versions d'un même package, et ça, ça peut être très utile, surtout quand on développe : avec des tar.gz, on maitrise mieux ce qu'on fait. Par exemple, sur ma machine de développement, j'ai 3 machines virtuelles java de veriosn différentes : une 1.1.5 (test et compil des applets, qui seront utilisées sur des navigateurs qui ont des JVM <= 1.1.5, sauf si plug-in), une 1.3, et une 1.4beta

Sinon, sur la FAQ boot, nul n'est besoin d'éditer le fichier Lilo.conf pour changer l'image de boot par défaut : y'a une option de la commande Lilo pour ça...Comme quoi, le bon vieux RTFM (Read The Fuckin' Manual) de ma première année d'école mérite encore d'être appliqué..

Bah sinon, pour ce que j'en ai lu, je trouve ça bien, cette FAQ!