Reprise du message précédent :

ca me tante bien de le testé ce logiciel mais vu que j'ai trop galéré pour utilisé ce mandriva je le ferai quand j'aurai un autre pc peut être mon portable
j'epsère qu'il ne va pas faire comme mandriake 10 car la mon pc portable reste écran noir après installation

=> gege38
mensonges! :
urpmq synaptic -i
Name : synaptic
Version : 0.55.1
Release : 1mdk
Group : System/Configuration/Packaging
Size : 3633070 Architecture: i586
Source RPM : synaptic-0.55.1-1mdk.src.rpm Build Host: n1.mandrakesoft.com
Packager : Michael Scherer <misc@mandrake.org>
URL : http://www.nongnu.org/synaptic/
Summary : Graphical package management program using apt.
Description :
Synaptic is a graphical front-end for APT (Advanced Package Tool).
It attempts to be a lot easier to use than other existing APT front-ends.

Instead of using trees to display packages, Synaptic is heavily based on a
powerful package filtering system. That greatly simplifies the interface
while giving a lot more flexibility to browse through very long package
lists.

éh oui ça existe sous mandriva aussi (j'ai jamais essayé!)
En fait c'est surtout une question d'habitude/apprentissage, le fait d'utiliser correctement les outils, ça n'ai jamais totalement instintinctif, il faut gratter... Je connais bien mandriva urpmi and co et je n'ai pas de problèmes particuliers, j'ai essayé plusieurs fois debian, une fois ubuntu et j'ai compris le truc, j'ai probablement pas insisté assez longtemps car mandriva me satisfait.

Ah mais keo ! Je suis désolé je croyais t'avoir donné le lien de easy urpmi mais visiblement je n'ai pas posté ici tu as perdu temps, escuse-moi!

Le 02 novembre 2005 - 15 h 06, manouchk a écrit : => gege38 mensonges! : [...] éh oui ça existe sous mandriva aussi (j'ai jamais essayé!)

Pour être précis, il s'agit de portages d'apt-get et Synaptic sous Mandriva, nuance
Et j'ai vu la différence quand j'ai porté apt-get sous Fedora Core 2. Certes, ca marche mais la gestion des dépendances est vraiment légère, légère (normal puisqu'il faut que les paquets soient aussi portés sous Fed2). Bien pour les paquets communs, ledge pour des paquets un peu moins connus ou demandés...

Maintenant, qu'on soit bien d'accord, je ne lancais pas un troll, je lui proposais de jeter un oeil quand il aurait le temps et l'envie à Ubuntu...

Ah, précision : je m'en fous de savoir quel est le meilleur format de paquetage du monde (rpm ou deb)... J'en ai déjà fait (que ce soit du deb ou du rpm) et franchement, ils sont aussi pourris tous les 2

le .deb est bien meilleur quand meme .. sinon ils auraient pas fait le portage

Le 02 novembre 2005 - 15 h 54, iraysyvalo a écrit : le .deb est bien meilleur quand meme .. sinon ils auraient pas fait le portage

Pas d'accord... Créer un deb, c'est juste faire une suite de scripts alakon permettant d'exécuter des commandes kivonbien... Ils ont pas inventé l'eau chaude quoi...
Résultat : un paquet deb fournissant de mauvaises méthodes de postrm (désinstall) va te pourrir le système et ledit système n'y verra que du feu...

Moi j'attend un vrai système de versioning de fichiers avec gestion des doublons... Et c'est pas deb, ni encore moins rpm qui vont le gérer (ah, j'oubliais : j'adore le fait de devoir chrooter et lister tous les fichiers futurs d'un rpm pour qu'il puisse s'installer )

Le 02 novembre 2005 - 16 h 05, gege38 a écrit : Le 02 novembre 2005 - 15 h 54, iraysyvalo a écrit : le .deb est bien meilleur quand meme .. sinon ils auraient pas fait le portage Pas d'accord... Créer un deb, c'est juste faire une suite de scripts alakon permettant d'exécuter des commandes kivonbien... Ils ont pas inventé l'eau chaude quoi... Résultat : un paquet deb fournissant de mauvaises méthodes de postrm (désinstall) va te pourrir le système et ledit système n'y verra que du feu...

Dans n'importe quel systeme que tu peux imaginer (oui meme celui de tes reves les plus fous), si tu (ton packageur/ton chien) fais n'importe quoi dans ta desinstall, c'est la merde .. ce n'est pas le systeme en soi qui pourra l'empecher : apres tout c'est l'homme qui a le controle.

Moi j'attend un vrai système de versioning de fichiers avec gestion des doublons...

Je croyais que c'est toi qui allait le sortir !!!!
D'ailleurs, je me souviens plus tres bien des cas d'apparition du probleme des doublons ..
(EDIT : plus precisement des cas ou ca poserait pb avec Deb par exemple)

Et c'est pas deb, ni encore moins rpm qui vont le gérer (ah, j'oubliais : j'adore le fait de devoir chrooter et lister tous les fichiers futurs d'un rpm pour qu'il puisse s'installer )

le chroot permet a priori de s'assurer (pour le soigneux) que l'on n'oublie pas une dependance importante .. ou veux-tu en venir ?

Le 02 novembre 2005 - 16 h 32, iraysyvalo a écrit : Dans n'importe quel systeme que tu peux imaginer (oui meme celui de tes reves les plus fous), si tu (ton packageur/ton chien) fais n'importe quoi dans ta desinstall, c'est la merde .. ce n'est pas le systeme en soi qui pourra l'empecher : apres tout c'est l'homme qui a le controle.

Faux. Dans le cas de mon système chéri, un script foireux n'aura d'incidence qu'au plus sur le logiciel donné... Il n'ira pas toucher à d'autres installs (comprends par là librairies and co.)

Moi j'attend un vrai système de versioning de fichiers avec gestion des doublons... Je croyais que c'est toi qui allait le sortir !!!! D'ailleurs, je me souviens plus tres bien des cas d'apparition du probleme des doublons .. (EDIT : plus precisement des cas ou ca poserait pb avec Deb par exemple)

Simple. Je vais reprendre mon bon vieil exemple :
Admettons que j'ai un logiciel A nécéssitant une librairie (glibc par exemple) D.

Avec apt-get, il va te proposer d'installer le logiciel A en version 1 et la lib en version 1 par exemple (soit A1 et D1 dans nos notations).

Plus tard, tu souhaites utiliser un logiciel B, nécéssitant aussi la lib D. Malheureusement, cette version de logiciel nécéssite la nouvelle version de la lib D, à savoir D2.

Concrètement, apt-get va te demander d'updater D alors...

Ben déjà là, c'est le bordel... Qu'est-ce qui te garantit que D2 aura les mêmes specs que D1 et sera compatible et utilisable par A ?
D'accord, les programmeurs sont des gens compétents, ils gardent une compatibilité ascendante (coucou PHP au fait )

Maintenant, tu as joué avec B, bouh, il te plait pas... Tu fais donc un apt-get remove non ? Ben, même en le purgeant, figure toi qu'il va pas désinstaller D (et heureusement puisque A en a besoin !)

Mais c'est moche : l'opération est pas réversible puisque tu as A1 avec D2 au final... C'est pas encore trop grave pour une ou deux applis, mais t'as moyen de pourrir rapidos ton systèmes avec des libs interdépendantes pas top compatibles entre elles (et dans le meilleur des cas, tes performances en pâtissent...)

Et c'est pas deb, ni encore moins rpm qui vont le gérer (ah, j'oubliais : j'adore le fait de devoir chrooter et lister tous les fichiers futurs d'un rpm pour qu'il puisse s'installer ) le chroot permet a priori de s'assurer (pour le soigneux) que l'on n'oublie pas une dependance importante .. ou veux-tu en venir ?

Non, c'etait juste une digression pour dire que lorsque l'on crée un RPM, on est théoriquement obligé d'indiquer dans le fichier de préparation (le fichier SPECS) la liste des fichiers et répertoires qui sera créé par l'opération d'installation (en gros, le contenu du tgz modulo les opérations d'installation). C'est ultra moche non ?
PS : Oui, je sais que l'on a moyen de contourner cetté étape via des outils comme find pour lister automatiquement le contenu, mais de base, waouh, quelle chiaderie !

Le 02 novembre 2005 - 17 h 08, gege38 a écrit : Le 02 novembre 2005 - 16 h 32, iraysyvalo a écrit : Dans n'importe quel systeme que tu peux imaginer (oui meme celui de tes reves les plus fous), si tu (ton packageur/ton chien) fais n'importe quoi dans ta desinstall, c'est la merde .. ce n'est pas le systeme en soi qui pourra l'empecher : apres tout c'est l'homme qui a le controle. Faux. Dans le cas de mon système chéri, un script foireux n'aura d'incidence qu'au plus sur le logiciel donné... Il n'ira pas toucher à d'autres installs (comprends par là librairies and co.)

Donne-moi un exemple ou meme les lib ont ete enlevees si elles sont encore utilisees ailleurs

Bon, j'attends ton systeme .. mais s'il y a un boulet qui fait n'importe quoi/procede n'importe comment, je vois mal comment tu peux l'empecher

Moi j'attend un vrai système de versioning de fichiers avec gestion des doublons... Je croyais que c'est toi qui allait le sortir !!!! D'ailleurs, je me souviens plus tres bien des cas d'apparition du probleme des doublons .. (EDIT : plus precisement des cas ou ca poserait pb avec Deb par exemple) Simple. Je vais reprendre mon bon vieil exemple : Admettons que j'ai un logiciel A nécéssitant une librairie (glibc par exemple) D.

glibc .. ca m'etonnerait .. tu n'y touches pas aussi impunement .. mais passons. (au fait, j'ai attendu un C quelque part mais .. vainement

Avec apt-get, il va te proposer d'installer le logiciel A en version 1 et la lib en version 1 par exemple (soit A1 et D1 dans nos notations). Plus tard, tu souhaites utiliser un logiciel B, nécéssitant aussi la lib D. Malheureusement, cette version de logiciel nécéssite la nouvelle version de la lib D, à savoir D2. Concrètement, apt-get va te demander d'updater D alors...

Je n'en suis pas aussi sur .. t'auras D2 avec D1 .. ou B sera peut-etre 'kept back'

Ben déjà là, c'est le bordel... Qu'est-ce qui te garantit que D2 aura les mêmes specs que D1 et sera compatible et utilisable par A ? D'accord, les programmeurs sont des gens compétents, ils gardent une compatibilité ascendante (coucou PHP au fait ) Maintenant, tu as joué avec B, bouh, il te plait pas... Tu fais donc un apt-get remove non ? Ben, même en le purgeant, figure toi qu'il va pas désinstaller D (et heureusement puisque A en a besoin !)

C'est contradictoire avec ce que tu dis sur la desinstall plus haut ..

Le 02 novembre 2005 - 20 h 12, iraysyvalo a écrit : Donne-moi un exemple ou meme les lib ont ete enlevees si elles sont encore utilisees ailleurs

Heu, pas compris ?
Dans les systèmes actuels, les libs ne sont pas enlevées, mais updatées au pire...

Un bon système peut déjà exister si l'on établit un graphe de dépendances entre logiciels (libs incluses). Il suffira alors pour désinstaller X de désinstaller toutes les dépendances incluses dans la fermeture transitive de X (cf. "théorie des graphes pour les nuls" pour plus d'infos )

Bon, j'attends ton systeme .. mais s'il y a un boulet qui fait n'importe quoi/procede n'importe comment, je vois mal comment tu peux l'empecher

Et le principe de la sandbox ? Si le bonhomme fait le cochon avec son soft, au pire, il bousille son soft... Il nique pas le système ni les autres logiciels...

glibc .. ca m'etonnerait .. tu n'y touches pas aussi impunement .. mais passons. (au fait, j'ai attendu un C quelque part mais .. vainement

Glibc est un exemple... Prenons libperl par exemple

Avec apt-get, il va te proposer d'installer le logiciel A en version 1 et la lib en version 1 par exemple (soit A1 et D1 dans nos notations). Plus tard, tu souhaites utiliser un logiciel B, nécéssitant aussi la lib D. Malheureusement, cette version de logiciel nécéssite la nouvelle version de la lib D, à savoir D2. Concrètement, apt-get va te demander d'updater D alors... Je n'en suis pas aussi sur .. t'auras D2 avec D1 .. ou B sera peut-etre 'kept back'

Tu peux être plus explicite ?
Parce que je ne connais pas cette option "'kept-back"...

Ben déjà là, c'est le bordel... Qu'est-ce qui te garantit que D2 aura les mêmes specs que D1 et sera compatible et utilisable par A ? D'accord, les programmeurs sont des gens compétents, ils gardent une compatibilité ascendante (coucou PHP au fait ) Maintenant, tu as joué avec B, bouh, il te plait pas... Tu fais donc un apt-get remove non ? Ben, même en le purgeant, figure toi qu'il va pas désinstaller D (et heureusement puisque A en a besoin !) C'est contradictoire avec ce que tu dis sur la desinstall plus haut ..

Heu, justement, en haut, je disais la même chose : la désinstall ne touche pas aux dépendances...

Le 02 novembre 2005 - 21 h 05, gege38 a écrit : Le 02 novembre 2005 - 20 h 12, iraysyvalo a écrit : Donne-moi un exemple ou meme les lib ont ete enlevees si elles sont encore utilisees ailleurs Heu, pas compris ? Dans les systèmes actuels, les libs ne sont pas enlevées, mais updatées au pire...

Je t'ai compris comme desinstall+toucher aux autres libs=les enlever ...

Un bon système peut déjà exister si l'on établit un graphe de dépendances entre logiciels (libs incluses). Il suffira alors pour désinstaller X de désinstaller toutes les dépendances incluses dans la fermeture transitive de X (cf. "théorie des graphes pour les nuls" pour plus d'infos )

Ce qui ne resout pas ton probleme de doublons si ton graphe ne tient pas compte des versions .. Pire, dans ta description actuelle, si libZ est dans la fermeture de X et que Y en depend, tu l'aura enlevee

Maintenant, Debian tient deja compte des versions et des dependances inverses ..

Bon, j'attends ton systeme .. mais s'il y a un boulet qui fait n'importe quoi/procede n'importe comment, je vois mal comment tu peux l'empecher Et le principe de la sandbox ? Si le bonhomme fait le cochon avec son soft, au pire, il bousille son soft... Il nique pas le système ni les autres logiciels...

Huh, tu ferais un sandbox pour chaque nouveau log installe ??

glibc .. ca m'etonnerait .. tu n'y touches pas aussi impunement .. mais passons. (au fait, j'ai attendu un C quelque part mais .. vainement ) Glibc est un exemple... Prenons libperl par exemple Avec apt-get, il va te proposer d'installer le logiciel A en version 1 et la lib en version 1 par exemple (soit A1 et D1 dans nos notations). Plus tard, tu souhaites utiliser un logiciel B, nécéssitant aussi la lib D. Malheureusement, cette version de logiciel nécéssite la nouvelle version de la lib D, à savoir D2. Concrètement, apt-get va te demander d'updater D alors... Je n'en suis pas aussi sur .. t'auras D2 avec D1 .. ou B sera peut-etre 'kept back' Tu peux être plus explicite ? Parce que je ne connais pas cette option "'kept-back"...

Non, ce n'est pas une option, c'est le systeme qui te repond qu'il ne lui sera pas possible pour l'instant de t'installer B par mesure de sanite .. (si tu veux absolument B, regardes le dernier prog que j'ai signale dans le topic Progs utiles )

Le 03 novembre 2005 - 08 h 25, iraysyvalo a écrit : Un bon système peut déjà exister si l'on établit un graphe de dépendances entre logiciels (libs incluses). Il suffira alors pour désinstaller X de désinstaller toutes les dépendances incluses dans la fermeture transitive de X (cf. "théorie des graphes pour les nuls" pour plus d'infos ) Ce qui ne resout pas ton probleme de doublons si ton graphe ne tient pas compte des versions .. Pire, dans ta description actuelle, si libZ est dans la fermeture de X et que Y en depend, tu l'aura enlevee Maintenant, Debian tient deja compte des versions et des dependances inverses ..

Roooo, tu ferais un piètre avocat Tu me fais dire ce que je n'ai pas dit, au contraire
J'ai bien précisé que mon système faisait du versioning... Là, le problème ne se pose pas...

On peut pousser le vice jusqu'à forcément doubler une librairie même si elle existe déjà, avant d'éviter les partages. Certes, on n'est plus dans le principe de librairies partagées mais au moins, on a un système stable...

Des expés l'ont prouvés, en patchant le kernel, et en mettant en UFS (User FileSystem) un FS versionisé, ca marche... Bon, d'accord, l'espace disque enfle sensiblement, mais je crois que le Go n'est plus vraiment une contrainte aujourd'hui

Seul détail : c'est encore des expés, et ce n'est pas embarqué dans une distrib "par défaut"... Mais je scrute l'actualité

Bon, j'attends ton systeme .. mais s'il y a un boulet qui fait n'importe quoi/procede n'importe comment, je vois mal comment tu peux l'empecher Et le principe de la sandbox ? Si le bonhomme fait le cochon avec son soft, au pire, il bousille son soft... Il nique pas le système ni les autres logiciels... Huh, tu ferais un sandbox pour chaque nouveau log installe ??

Oui, et je ne vois pas ce qui nous y oppose (cf. argumentaire plus haut). Pareil, des expés ont été concluantes

glibc .. ca m'etonnerait .. tu n'y touches pas aussi impunement .. mais passons. (au fait, j'ai attendu un C quelque part mais .. vainement ) Glibc est un exemple... Prenons libperl par exemple Avec apt-get, il va te proposer d'installer le logiciel A en version 1 et la lib en version 1 par exemple (soit A1 et D1 dans nos notations). Plus tard, tu souhaites utiliser un logiciel B, nécéssitant aussi la lib D. Malheureusement, cette version de logiciel nécéssite la nouvelle version de la lib D, à savoir D2. Concrètement, apt-get va te demander d'updater D alors... Je n'en suis pas aussi sur .. t'auras D2 avec D1 .. ou B sera peut-etre 'kept back' Tu peux être plus explicite ? Parce que je ne connais pas cette option "'kept-back"... Non, ce n'est pas une option, c'est le systeme qui te repond qu'il ne lui sera pas possible pour l'instant de t'installer B par mesure de sanite .. (si tu veux absolument B, regardes le dernier prog que j'ai signale dans le topic Progs utiles )

Oui, enfin, interdire d'installer une librairie, c'est pas pallier le problème, que je sache

Ben, tu ferais pas un meilleur avocat

Car tu ne m'as guere convaincu sur le coup des doublons .. puisque j'ai deja vu deux versions d'une meme librairie cohabiter sans probleme ..

Et pour le coup des sandbox, ce n'est pas qu'une question d'espace .. a la limite si on suit ton raisonnement jusqu'au bout, on compile tout en statique.

Je ne sais d'ailleurs si on peut encore appeler un tel systeme une distribution, c'est plutot une sorte de plateforme virtuelle .. ou on changerait de 'sandbox' si on veut le log A2 avec libC3 et on se mettrait dans un autre si on veut B4 avec libC2.3 : un vrai calvaire pour l'utilisateur ..

Le 03 novembre 2005 - 11 h 04, iraysyvalo a écrit : Ben, tu ferais pas un meilleur avocat

Bon, ca me rassure dans mes choix de carrière

C'est clair que Boulet et associes, ca l'aurait pas trop fait

ouh la la c'est partie loin!!
question : c'est les dépendances inverses?

réponse : mandrake et ses rpms supportent tout à fait bien le fait d'avoir plusieurs version de librairies, par exemple libfftw3 et 2... Par contre j'ai pas encore tout capté, mais dans 15-20 ans, je promets que je vai étudier ça (quand ils auront trouvé mieux hé! hé!

Le 02 novembre 2005 - 15 h 54, iraysyvalo a écrit : le .deb est bien meilleur quand meme .. sinon ils auraient pas fait le portage (d'APT)

Un petit article de 2002 sur le RPM d'alors