[résolu] Dépendances cumulées

Bonsoir

Lorsque je suis dans synaptic, un certain nombre d’applications dépendent de python. Malheureusement ces dépendances se signalent dès que je veux désinistaller une des versions installées. OR j’ai a priori 4 versions de python installées:
2.3.5-15
2.4.3-8 (existe en normal ET minimal)
2.4.3-11
2.5.c1-1

Je ne souhaiterais garder que la dernière. Une idée pour m’aider?

Et dans la même veine, comment faire pour qu’un paquet A installé avec la dépendance sur python 2.3 ne râle pas lorsqu’on ne dispose “que” d’un python 2.5

Merci d’avance

On ne peut pas faire ça utilement ni facilement: si un paquet te demande une certaine version de python, c’est qu’il ne fonctionne pas avec une autre.
Tu peux essayer d’enlever les versions de python qui n’ont pas de dépendances, ou enlever celles que tu veux avec leurs dépendances.

Je prends l’exemple de gdebi. Il demande un python >=2.3. Dès que je veux supprimer une des versions, synaptic me signale que pour des raisons de dépendances, il doit désinstaller gdebi (et d’autres, comme alacarte, eog, …).
Je suis donc en train de penser que je dois pouvoir avec un dpkg lui dire de me supprimer les paquets python qui ne me servent pas sans vérifier les dépendances, puis faire un check des dépendances sur les paquets installés pour vérifier qu’ils s’en sortent tous avec le python restant.
Car un paquet qui demande python = 2.3 strict, a de grandes chances de fonctionner avec une 2.5, les version étant rétro-compatibles.

Non?

non. Si c’etait le cas, apt aurait été configuré pour, et te laisserait désinstaller le 2.3 en considèrant qu’un 2.5 est suffisant.
Ce qui ne veut pas dire qu’en installant depuis les sources, tu n’obtiendrait pas quelquechose d’utilisable à ton sens, mais les equipes d’empaquetage debian on dû juger que ton gdebi ne devait bien fonctionner QUE avec un python 2.3, et pas avec un 2.5.

Ce qui est bizarre par contre, c’est que le paquet gdebi ne demande effectivement pas une version particulière de python, mais une version minimale.
Oublies donc cette saleté de synaptics et essayes plutot de passer par un 'aptitude remove ’ pour supprimer les versions de python que tu penses inutiles.

Test de ce soir:
je force le remove du python 2.3 avec la commande:

Seule solution connue. Aptitude, même en décochant les options de non controle des dépendances, fait la suggestion automatique de suppression des paquets liés.
Et quand je reverifie mon systeme avec:

j’ai, entre autres:

Ce qui signifie bien que le controle de version est bidon, sauf à installer un méta-paquet python2.3 avec comme version 2.5, et là ça devrait marcher.
Et ce sont des conditions comme celles-là qui conduisent à avoir 5 packages de runtime python sur une même distrib (même si deux sont pour du dev pur (python2.5 et python2.5-minimal, qui ne correspondent pas à la dernière stable).

quote="mathiasm"
j’ai, entre autres:

Ce qui signifie bien que le controle de version est bidon, sauf à installer un méta-paquet python2.3 avec comme version 2.5, et là ça devrait marcher.
Et ce sont des conditions comme celles-là qui conduisent à avoir 5 packages de runtime python sur une même distrib (même si deux sont pour du dev pur (python2.5 et python2.5-minimal, qui ne correspondent pas à la dernière stable).[/quote]Mais non, je n’avais pas fait attention au nom de ce paquet: python2.3, mais c’est bien un soft considèré comme différent de python2.5 dans le systême apt: je ne vois pas ou tu peux dire que c’est bidon.
Maintenant, tu as encore une autre possibilité si tu veux continuer à te prendre la tête pour faire mal marcher ta machine, tu peux déclarer python2.5 comme équivalent à python2.3 avec equivs:[code]emeraude:~/rtl8187/rtl8187_linux_26.1010.0622.2006$ aptitude show equivs
Paquet : equivs
État: non installé
Version : 2.0.7
Priorité : supplémentaire
Section : admin
Responsable : Peter Samuelson peter@p12n.org
Taille décompressée : 131k
Dépend: perl, debhelper (>= 4), dpkg-dev, devscripts, make, fakeroot
Description : Circumvent Debian package dependencies
This package provides a tool to create Debian packages that only contain dependency information.

One use for this is to create a metapackage: a package whose sole purpose is to declare dependencies and conflicts on other packages so that these will be
automatically installed, upgraded, or removed.

Another use is to circumvent dependency checking. If a package P is not installed on the system, packages that depend on P cannot normally be installed.
However, if functionality equivalent to P is known to be installed, this tool can be used to trick the Debian package management system into believing
that package P is actually installed. NOTE: this should be considered a crude hack to work around awkward situations, not a normal solution. If you use
equivs to work around bugs in other Debian packages, you should also file bug reports against those packages.

Marqueurs: admin::package-management, devel::packaging, interface::commandline, made-of::lang:perl, role::sw:utility, suite::debian,
works-with::software:package
[/code]Mais je te répète: si les équipes debian ont découpé de cette manière, c’est voulu.
Et si tu veux un linux qui se foute des dépendances, tu n’as qu’a tout compiler…
Je ne vois pas trop ce qui te gène à avoir plusieurs versions de python.

Non, je parlais du système de version. Mettre en dépendance python2.3 et mettre en clause de version >=2.3, je ne vois pas à quoi sert le “>”…

Je te rassure (si nécessaire, j’ai arrêté). Je trouvais inutile de se trimbaler de 3 à 5 versions de binaires pour un seul runtime. Et python n’est qu’un exemple que je venais de constater.

Merci pour les infos sur equivs.

De la même manière que les dépendances de python nécessitent une version particulière, tu as aussi le gcc qui est en version multiple, parceque tout ne se compile pas avec le même gcc.
Et sinon, le >=, c’est pour les versions 2.3-sarge0, par exemple, qui restent des 2.3, mais qui peuvent continuer à evoluer avec les corrections de equipes debian.

Je crois que ce qui se situe avant le ‘_’ est le nom du paquet. Ce qui est après correspond à la version. machin4.2_3.6 est un paquet différent de machin4.3_2.7 (pas une version différente de ‘machin’).

Je répète ce qui est dit plus haut en gros…

[quote=“mathiasm”]
Car un paquet qui demande python = 2.3 strict, a de grandes chances de fonctionner avec une 2.5, les version étant rétro-compatibles.

Non?[/quote]
Non! J’ai plusieurs programmes qui tournent sous python2.1 et pas python2.3. Ça n’est pas parce que c’est libre, que ça tourne sous linux, que c’est un bon produit: Python a été très décevant sur cet aspect: on se croirait sous Word avec l’obligation d’utiliser pile la bonne version. J’ai arrêté d’apprendre python dès que j’ai vu ça…