Une boite basée en Israel et à Palto Alto (Aduva) développe un manager graphique de packages RPM qui supporte les dépendances comme le fait apt-get (ne ratez pas les screenshots qui perso me laissent perplexes) .
Toutes les distribs basées sur RPM proposent aujourd'hui un outil du genre (type rpmdrake pour MDK). L'avenir des packages RPM et des outils pour le gérer n'est pas très clair... quelles sont vos opinions sur le sujet ?
Aller plus loin
- Edito Freshmeat sur apt-get/RPM (3 clics)
- Package manager Aduva (1 clic)
- Screenshots Aduva Manager (6 clics)
# vive les tarballs
Posté par Anonyme . Évalué à 0.
J'aime beaucoup le système de tarball de la slackware :
installpkg fichier.tgz
removepkg fichier
Jesus
[^] # Re: vive les tarballs
Posté par Pat Le Nain . Évalué à 1.
Mais c'est son boulot de vérifier les dépendances (tu veux installer un soft mais tu ne sais pas quels libs sont nécessaires), la conformité des fichiers installés par rapport au package original (sécurité) et plein d'autres choses encore. Ds RPM, il ya PM pour Package Manager. C'est un outil très puissant quand on a appris à s'en servir.
[^] # Re: vive les tarballs
Posté par Anonyme . Évalué à 0.
perso c pas plus compliqué, et les options peuvent etre très pratique ( allez utiliser un binaire rpm de xchat qui a été créé avec le support de gnome quand on a rien de gnome sur sa becane :p )
pour moi les packages.. c pas encore ca.... de plus les editeurs font chacun leur sauce, avec des chemin parfois differents pour les lib ...
mais il faut avouer que pour quelqu'un qui decouvre le monde linux le rpm s'il est correctement utiliser peut vraiment simplifier la vie...
[^] # Re: vive les tarballs
Posté par dguihal . Évalué à 1.
[^] # Re: vive les tarballs
Posté par Anonyme . Évalué à 0.
Exemple typique : Apache sur RH. rpm -e (en mettant de cote peut-etre le script de demarrage/stop sous /etc/rc.d/init.d histoire de l'adapter plus tard ;-) ) et ensuite une reinstallation du tar.gz et ./configure "d'origine" ou presque sous /usr/local/src.
Idem pour d'autres softs qui evoluent vite (PostgreSQL ou PHP par exemple).
Il est sur que dans ce cas, il faut etre rompu aux arcanes des recompilations de tout ca en meme temps.
On en arrive a quelquechose de plus propre, avec un "core" de la distribution qui evolue en rpm et quelquechose de plus personnel sur lequel on veut avoir plus de prise (ou reactivite quant a la disponibilite des dernieres moutures...) sous /usr/local/.
De ce que j'ai vu de ma rapide incursion sous FreeBSD, c'est un peu organise de la sorte (et avis personnel, c'est plus propre).
Pour le reste, les tar.gz comportent souvent un fichier .spec qu'il suffit eventuellement d'adapter pour le cas personnel et un rpm -ta <tarball> permet de regenerer a partir des sources le rpm source, binaire qui va bien.
La gestion de package est de toute facon l'element essentiel pour qu'une distribution tienne la route. Sans ca, ca devient ingerable et on perd plus de temps a bricoler et a rendre le systeme pourri non pas seulement en termes de fonctionnalites mais aussi de maintenance.
Meme Microsoft l'a pige maintenant en reinstallant des DLL essentielles au systeme eventuellement sur des DLL qui viennent d'etre installees par une appli, ce afin de conserver l'integrite du systeme parfois au depend du bon fonctionnement d'une appli.
Apres tout, il est surement plus important d'avoir la base installee de l'OS propre qu'un truc qui merde parce que les applis installees ont aide a le veroler. Ceci est valable au moins sous sous Windows 2000 mais aussi sur Linux ou autre, gere par les pre et post installations qui sont des elements essentiels des gestionnaires de package, avec la gestion de signature (cf intervention precedente).
Voir l'excellent bouquin disponible en ligne sur les fonctionnalites des RPM : http://www.rpm.org/(...) chapitre Documentation, disponible au format PostScript ou LaTeX. Interessant pour comprendre la gestion de packages.
[^] # Re: vive les tarballs
Posté par Damien Sandras (site web personnel) . Évalué à 1.
Au début que j'étais sous linux aussi je me débattais avec les dépendances, jusqu'à en comprendre le fonctionnement, ce qui facilite la chose quand-même, mais quand on débute...
Enfin, il y a presque 2 ans, j'ai installé Debian, et depuis, j'installe et désinstalle des softs facilement...
Espérons que l'apt-get sur rpm permettra cela, mais je n'y crois pas à cause de la fragmentation au niveau des packages rpm.
[^] # Re: vive les tarballs
Posté par bmc . Évalué à 1.
[^] # Re: vive les tarballs
Posté par GuiJEmonT . Évalué à 1.
le prog sera installé, et mis dans la base de donnée des pkgs installés, il sera donc desinstalable d'un simple removepkg machin. C'est franchement très pratique, et ça merite d'être connu. Les developpeurs de ce machin ont d'ailleurs prévu de le rendre compatible avec les systemes de package rpm et deb il me semble, ce qui éviterait peut-être les problemes de dépendance pour les packages installés depuis les sources.
[^] # Re: vive les tarballs
Posté par Pat Le Nain . Évalué à 1.
* scripts d'installation (avant et après copie des fichiers),
* scripts de désinstallation (avant et après suppression),
* signature pgp,
* stockage des tailles, dates, droits et sommes md5 des fichiers installés,
* description des packages (texte, auteur, date de compil, machine, ...),
* séparation des fichiers de développement (entêtes) et de production (.so et exécutables) (cas des librairies),
* pas besoin de compiler à chaque installation (je sais, pour les tarballs de slackware ya pas besoin de recompiler),
* capacités d'interrogation importantes,
bref que du bon.
[^] # Re: vive les tarballs
Posté par Anonyme . Évalué à 0.
[^] # Re: vive les tarballs
Posté par Pat Le Nain . Évalué à 1.
Les deux points de vue se valent, l'important étant d'avoir le choix.
[^] # Re: vive les tarballs
Posté par Anonyme . Évalué à 0.
ldconfig -p | grep libmachin
pour savoir si la lib machin est la, et dans la bonne version, mais pas forcément en mode rpm.
pour ce qui est de Debian je ne connais pas ses packages ...
pour le moment je reste sur le système tarball de la slack, qui contiennent :
. les binaires
. un script d'install
. un script de remove
le tout gérer par 2 utilitaires (installpkg|removepkg), mais il est vrai qu'il ne fait de checkup des dépendances, ce qui peut poser des problèmes pour les débutants.
Jesus
[^] # Re: vive les tarballs
Posté par Pat Le Nain . Évalué à 1.
[^] # Re: vive les tarballs
Posté par Anonyme . Évalué à 0.
Lorsque j'ai compilé une librairie, le système des packages me crie dessus parce que je n'est pas cette librairie ...
En tout cas, les packages debian sont plutôt les meilleurs
(et pourtant, j'en est testé des distrib' boudiou !! ;)
# screenshots
Posté par Loic Jaquemet . Évalué à 1.
c ou kon d/l ?
[^] # Re: screenshots
Posté par dguihal . Évalué à 1.
voila voila voila.
[^] # Re: screenshots
Posté par Anonyme . Évalué à 0.
C'est visuellement lourd et lassant (un peu comme le Aqua de MacOS).
(imbitable, avec un 'm' et pas un 'n').
Sur debian, on a apt-get pour la ligne de commande, aptitude en ncurses, gnome-apt pour les furieux de la souris.
Et les dépendances sont gérées aussi pour les paquets sources (pas pour tous, d'accord).
-- Charles (charles.goyard@laposte.net)
[^] # Re: screenshots
Posté par Anonyme . Évalué à 0.
Puis-je savoir en quoi c'est de la merde ? AH oui, excuse moi, ca ne rentre pas dans ton monde monochrome ...
He les mecs, faut peut etre arrete un peu d'etre fasciste et etaleur de confit.
Si un tel logiciel existe, c'est qu'il y a une demande, et tant pis si les gnomes (dans tout les sens du terme) n'aiment pas ...
Cet manie de tout le temps penser que l'on est le meilleur parce que on utilise tel outil et pas tel autre montre bien l'etat d'esprit pueril general qui regne ici.
Toi qui est si prompt a traiter ce soft de "grosse merde", fait mieux, vas-y, produit un soft qui tue tout sur son passage, tu doit en etre capable puisque tu te permet de traiter le travail des autres de "merde".
[^] # Re: screenshots
Posté par Aurelien Gateau (site web personnel) . Évalué à 1.
[^] # Re: screenshots
Posté par Anonyme . Évalué à 0.
[^] # Retour d'expérience...
Posté par Anonyme . Évalué à 0.
Désolé mais j'ai du mal à retenir le mot de passe (j'en manipule déjà 15 par jour...) pour m'authentifier.
[^] # Re: Retour d'expérience...
Posté par Pat Le Nain . Évalué à 1.
[^] # Re: Retour d'expérience...
Posté par Anonyme . Évalué à 0.
Adimante
# Ca existe deja
Posté par dguihal . Évalué à 1.
[^] # Re: Ca existe deja
Posté par Pat Le Nain . Évalué à 1.
[^] # Re: Ca existe deja
Posté par bmc . Évalué à 1.
[^] # Re: Ca existe deja
Posté par dguihal . Évalué à 1.
# Paquet ok, mais c ki ki les fait ?
Posté par charles vidal . Évalué à 1.
force de debian est ,ou plutot, sont les developpeurs debian.
Est-ce que le probleme n'ai pas plutot qui fait
les paquets ? car cette personne a potentielement les droits roots sur les machines ou est installe son paquet ...
( desole pour le titre neuneu, oups je vais encore me faire attraper par la gente feminine :).
[^] # Re: Paquet ok, mais c ki ki les fait ?
Posté par charles vidal . Évalué à 1.
Je crois,(virgule) bien que je puisse me tromper, (virgule) que la force de debian est ....
Tout le monde aura compris :)
( desole pour le probleme n'est ... :(.
Pas la peche aujourd'hui :(.
[^] # Re: Paquet ok, mais c ki ki les fait ?
Posté par Pat Le Nain . Évalué à 1.
[^] # Spécial paranos!
Posté par Matthias Saou . Évalué à 1.
rpm -qpl lerpm.rpm <- liste les fichiers qu'il contient *ou* qu'il va s'accaparer
rpm -qpi lerpm.rpm <- donne des infos sommaires (et facilement falsifiables comme le build host, attention!)
rpm -qp --scripts lerpm.rpm <- va lister tous les scripts executés avant/après l'installation et avant/après la désinstallation
rpm -K lerpm.rpm <- vérifie le md5 du fichier et sa signature pgp ou gpg si elle est présente
Après avoir fait le tour d'un RPM avec tout ça et s'il n'y a rien d'anormal, le rique le plus évident est écarté... ensuite reste à voir le contenu des fichiers installés :-)
[^] # Re: Spécial paranos!
Posté par Anonyme . Évalué à 0.
te donne toutes les modifs ( seulement si les packageurs
ont fait l effort de mettre leurs modifs...)
# La diversité des distributions à base de RPM
Posté par Matthias Saou . Évalué à 1.
* D'autres soulignent qu'ils préfèrent installer depuis les sources...
Personnellement j'adore les RPMs car c'est le juste milieu entre ces deux opinions! Je m'explique :
Les dépendences ne sont pas *automatiquement* gérées et ça, personnellement j'adore! Si je disais "je veux ce jeu pourri" et qu'au final j'avais 150Mo de librairies en tout genre sans rien avoir demandé, je n'aimerais pas... (j'ai volontairement poussé l'exemple à l'extrème)
D'un autre côté, en installant depuis les sources il manque souvent d'autres packages qu'il faut aller récupérer ici ou là et... recompiler à chaque fois! Il faut aussi tout recompiler autant de fons qu'on a de machines... mais c'est pas là le pire, le pire c'est pour faire des mises à jour! Je ne dis pas que c'est dur, mais simplement que c'est complexe pour pas grand chose : sauvegarder ses fichiers de configuration, prier pour que des fichiers n'aient pas changé d'emplacement...
Pour moi les RPMs c'est un peu comme les packages slackware ou les ports FreeBSD : C'est bien foutu, mais on garde encore un contrôle total sur ce que l'on fait!
Un RPM bien fait s'installe à la perfection (dépendances, création de comptes systèmes), se met à jour à la perfection (maintien de l'ancienne conf sauf si le format de fichier a changé) et se désinstalle à la perfection (sauvegarde des fichiers de conf uniquement s'ils ont été modifiés).
Le seul point négatif que je trouve aux RPMs, c'est qu'étant donné la diversité des distributions qui utilisent ce "format", et vu qu'elles n'ont pas toutes le même fonctionnement pour certaines parties (scripts d'init, arborescence de confs...), il est impossible de faire un seul RPM binaire par architecture...
Personnellement je n'utilise plus que des RedHat 7.0 depuis sa sortie, et je n'ai _JAMAIS_ rien installé à partir des source (à part des noyaux ;-). Ce que je fais, c'est que je crée un RPM moi-même (s'il n'en existe pas déjà un fait par RedHat ou par l'auteur) et je le met à disposition de tout le monde... bien souvent d'ailleurs (pour gkrellm et lbreakout par exemple), je me retrouve à faire les RPMs "officiels". C'est une façon comme une autre de contribuer :-)
Tous mes RPMs pour RedHat 7.0 (xine, gkrellm, tuxracer, ircd, lame, nessus, proftpd et beaucoup d'autres) :
http://www.aldil.org/ftp/(...)
Longue vie à Linux et à sa diversité ;-)
Matthias
[^] # Re: La diversité des distributions à base de RPM
Posté par Anonyme . Évalué à 0.
# make install
Posté par Anonyme . Évalué à 0.
[^] # Re: make install
Posté par Anonyme . Évalué à 0.
[^] # Re: make install
Posté par Anonyme . Évalué à 0.
t'ajoutes /opt/nomdusoft a ton PATH
et quand tu veux le virer rm -rf /opt/nomdusoft en tout cas ca marche chez moi
[^] # Re: make install
Posté par Babou . Évalué à 1.
(jumble signifie "fourre-tout" en anglais) avec
dedans des répertoires bin, lib, etc, share ...
Les répertoire lib et bin contiendront des liens
symboliques vers les fichiers des réps. bin et lib de chaque package (attention aux conflits éventuels de noms). share contiendra des liens les répertoires share des applis. etc ... soit des liens vers les fichiers des divers etc/ ou d'autres structures au choix ...
J'allais oublier: même principe avec sbin/, et man/man*/, doc/, info/ et include/
Qd tu supprimes/mets à jour un package, tu supprimes les symlinks vers le package supprimé. C'est facile à faire avec un ls -l | grep repappli | awk '{print $9}' . Y a mieux que awk mais je sais plus faire.
Reste à rajouter /opt/jumble/lib dans ton LD_LIBRARY_PATH, voire dans /etc/ld.so.conf et /opt/jumble/bin dans ton PATH.
Je tourne sous Debian Woody, mais certaines applis ne sont pas dispo en .deb. J'utilise donc ce système pour compiler des progs. En plus, tout les progs compilés maison étant dans /opt, un tar | rsh suffit pour le copier sur une autre machine. J'ai ainsi compilé AfterSte 1.8.4, xmps, ... et aussi mis StarOffice, quake3 ... qui n'ont pas vraiment leur place ailleurs (peut-être dans /usr/local, mais je ne me sers pas de cet emplacement).
[^] # Re: make install
Posté par Anonyme . Évalué à 0.
./configure --prefix=/usr (par exemple)
make
Pour installer et avoir la liste des fichiers installés, tu as juste à créer un package slackware comme suis dans 99,80% des cas :
make prefix=$PWD/fakeRoot/usr install
Dans fakeRoot, tu auras l'arborescence des fichiers qui seront installés. Si tu es sous Slackware comme tu l'as dit, tu fais :
cd fakeRoot
su
chown root.root -R *
makepkg packagename.tgz (voila un pkg slack !)
installpkg packagename.tgz
Dans /var/log/packages/packagename, tu auras la liste des fichiers installés. Pour désinstaller proprement, tu fais removepkg packagename.
Efficace, propre, slackware bref ;-) Parfois, ça ne fonctionnera pas car le make install devra changer le propriétaire, ajouter des utilisateurs et tuti quanti. Dans ce cas, tu peux utiliser installwatch (cherche avec google) pour avoir la liste des fichiers installés puis créer ton prpore package slack si tu es sous Slack.
Notez que si vous n'êtes pas sous Slack, installwatch est assez pratique pour voir ce qui a été installé, modifier, etc.
Bref, chacun sa distro, chacun ses choix : tout dépend des besoins de chacun (pour peu qu'on passe le temps à les évaluer et à se renseigner sur les distros bein sûr).
LiNuCe !
[^] # Re: make install
Posté par Anonyme . Évalué à 0.
# C'est pas dans la LSB ?
Posté par Anonyme . Évalué à 0.
[^] # Re: C'est pas dans la LSB ?
Posté par Anonyme . Évalué à 0.
Quand je désire récupérer un programme au format RPM je suis obligé de vérifier pour quelle distrib il a été compilé, en effet :
1) Suivant la distro d'origine, les dépendances du programme seront non résolues.
2) Les programmes installeront des fichiers dans des répertoires qui n'existaient pas avant. (exemple /usr/doc à la place de /usr/share/doc)
Donc le programme que je récupère n'est pas forcément fonctionnel.
Après avoir pendant des années fonctionné en réinstallant régulièrement mes distros puisque les dépendances craignaient trop pour laisser un système stable j'ai décidé de me mettre à la debian depuis quelques mois. Parceque les personnes qui développent les deb utilisent tous la même file hérarchie, les mêmes lib etc.
Maintenant je ne dis pas que deb est meilleur que RPM, je pense juste que pour l'utilisateur final le format deb est moins générateur de problèmes que le format rpm.
La FHS va peut être changer les choses mais j'en doute parceque dans un milieu économique je vois mal les distros chercher à faire du standard et donner leurs programmes phares aux autres distros (avis personnel, troll bare en booleen, SVP!). Et ca c'est dommage parceque franchement je ne vois pas l'avantage du deb sur les rpm ou vice versa, c'est juste la question de la philosophie sous-jacente qui me gène.
# Simplicité et clareté
Posté par Anonyme . Évalué à 0.
[^] # Re: Simplicité et clareté -> gnome-apt rulez
Posté par Anonyme . Évalué à 0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.