annuler une installation via PPA ?

YannUbuntu · Le 12/11/2009, à 08:10

Dernièrement j'ai testé Openshot via son PPA, qui m'a mis a jour de nombreux paquets (codecs vidéos) utilisés par d'autres logiciels, notamment VLC et Totem qui du coup ne fonctionnaient plus.

J'ai solutionné le problème en virant le PPA et en réinstallant tous les paquets originaux. Bien-sur je savais ce que je faisais, et je suis bien conscient que l'utilisation d'un PPA n'est pas recommandée. Mais si je me mets dans la peau d'un débutant, je me dis qu'il y a quand même des choses à améliorer...

Par exemple ça aurait été bien que :
(1) au moment d'installer les paquets du PPA: que Synaptic permette de manière simple de voir la liste des logiciels qui utilisent les paquets allant être modifiés par ceux du PPA. Cela aurait permis par exemple de mettre en évidence que VLC et Totem allaient être impactés.
(2) lorsque l'on retire le dépôt PPA: que Synaptic permette de remettre les paquets originaux.

Savez-vous si un gestionnaire permet ce genre de choses?

xabilon · Le 12/11/2009, à 08:17

Salut

Oui, aptitude (et aptitude va bientôt avoir une interface graphique Gtk).
Mais bon, c'est moins user-friendly que ce à quoi tu dois penser ...

YoBoY · Le 12/11/2009, à 09:02

Ben synaptic aussi permet ça suffit de cliquer sur le gros bouton "Origine" en bas à gauche, de choisir le dépôt en question et là on voit tout. On choisit le paquet qu'on veut installer, ensuite on va dans le menu "Paquet > propriétés" et les onglets nous en apprennent encore plus, surtout les dépendances, bon après faut éventuellement savoir quelles sont les dépendances fournies par le dépôt de celles qui ne le sont pas mais souvent si un dépôt fournis ses dépendances, on les aura vu dans la liste des paquets avec "Origine".

vikin · Le 12/11/2009, à 09:21

Bonjour

YannUbuntu a écrit :

(1) au moment d'installer les paquets du PPA: que Synaptic permette de manière simple de voir la liste des logiciels qui utilisent les paquets allant être modifiés par ceux du PPA. Cela aurait permis par exemple de mettre en évidence que VLC et Totem allaient être impactés.

Le problème c'est que lorsque l'on utilise plusieurs dépôts différents, ils peuvent impacter plusieurs dépendances. Et des fois certains plusieurs fois le même paquet.
Donc tout cela dépend de comment a été compilier le paquet et des dépendances qui modifiera et de celles qu'il rajoutera.
Dans ce cas il se peut qu'au prochain ajout d'un dépôt tiers, il est du mal à détecter quels seront les logiciels impactés.

YannUbuntu a écrit :

lorsque l'on retire le dépôt PPA: que Synaptic permette de remettre les paquets originaux.[/b]

C'est un peu le problème que j'avais soulevé dans le ML par rapport au problème de sécurité lié à l'ajout d'un dépôt.
Lorsque tu ajoutes un dépôt, celui-ci remplace et des fois rajoute des dépendances, et lorsqu'une mise à jour officielle arrive, celle-ci ne prend pas en compte les dépendances modifiées par le dépôt. ( Même si elles sont plus récentes que celles présentes dans le dépôt ajouté )
Pour qu'une restauration soit possible, il faudrait un système qui désinstalle complètement les ajouts fait par le dépôt.
mais ce système pourrait être vite problématique dans certains cas. Il y a des fois ou certains dépôts ajoutés modifient grandement les dépendances et leurs suppression et réinstallation n'est pas à la portée de tous.

Dernière modification par vikin (Le 12/11/2009, à 09:22)

percherie · Le 12/11/2009, à 09:37

Je n'ai pas la réponse à ton problème mais je serait fortement interessé par une solution qui permette tout ça.

YoBoy je n'ai pas vu de bouton origine mais sur Jaunty je viens de découvrir ceci >edition>sélectionner les paquets par tâche

draco31.fr · Le 12/11/2009, à 10:01

vikin a écrit :

Lorsque tu ajoutes un dépôt, celui-ci remplace et des fois rajoute des dépendances, et lorsqu'une mise à jour officielle arrive, celle-ci ne prend pas en compte les dépendances modifiées par le dépôt. ( Même si elles sont plus récentes que celles présentes dans le dépôt ajouté )

A moins d'avoir forcé la version d'un paquet (via synaptic ou autre) c'est toujours la version la plus récente qui est installée par un upgrade.
Donc si les dépots officiels proposent une version plus récente d'un paquet installé que celle disponible dans un PPA, c'est le dépôt officiel qui prime.

Autre suggestion :
Avant de lancer un upgrade ou une install d'un paquet venant d'un PPA, je lance une première fois la commande avec l'option "-s" (simulate ?) pour "voir" ce que va faire apt-get sans rien toucher.
Si ça me va, je relance la commande sans le "-s".

Je ne sais pas comment ça se passe avec Aptitude.

vikin · Le 12/11/2009, à 10:23

draco31.fr a écrit :

A moins d'avoir forcé la version d'un paquet (via synaptic ou autre) c'est toujours la version la plus récente qui est installée par un upgrade.
Donc si les dépots officiels proposent une version plus récente d'un paquet installé que celle disponible dans un PPA, c'est le dépôt officiel qui prime.

Non ce n'est pas toujours le cas.
dans le cas ou un paquet a été modifié par un PPA et qu'il a ajouté une dépendance propre à celui-ci, la mise à jour officielle ne prendra pas le dessus puisqu'elle ne gérera pas la dépendance.

Après avoir eu quelques problèmes de ce genre, j'ai testé sur deux installations identiques.
Sur l'une en ajoutant des dépôts et l'autre en ne modifiant rien.
Et résultat, sur l'installation non modifiée pas de problème. Sur l'installation avec plusieurs PPA, certaines mise à jour n'étaient même pas proposées.

draco31.fr · Le 12/11/2009, à 14:15

Ce que tu décris est différent.
Si la mise à jour n'est pas proposé, c'est que la version fournie dans le PPA est déjà plus récente que la mise à jour versé au dépôt officiel.
Dans ce cas, il n'y a pas lieu d'installer la version du dépôt officiel puisqu'elle occasionnerai en une régression.

Pour bien comprendre tout ça, il suffit de faire un "apt-cache show nom_du_paquet" ou un "apt-cache policy nom_du_paquet".
S'il y a plusieurs bloc/lignes, c'est que le paquet est présent dans plusieurs dépôts (PPA, officiel, canonical ...).
La valeur de la ligne "version" permet de déterminer le dépôt qui dispose du paquet le plus récent.
Par exemple, chez moi pour MPlayer :

apt-cache policy mplayer
mplayer:
Installé : 2:1.0~rc3+svn20090904-0jaunty2
Candidat : 2:1.0~rc3+svn20090904-0jaunty2
Table de version :
*** 2:1.0~rc3+svn20090904-0jaunty2 0
500 http://ppa.launchpad.net jaunty/main Packages
100 /var/lib/dpkg/status
2:1.0~rc2-0ubuntu19+medibuntu1 0
500 http://packages.medibuntu.org jaunty/non-free Packages
2:1.0~rc2-0ubuntu19 0
500 http://fr.archive.ubuntu.com jaunty/multiverse Packages

Le PPA ayant une version plus récente que les autres dépôts, c'est celle-ci qui est installée.
Si je retire le PPA de mon sources.list, que je désinstaller le paquet mplayer, et que je purge le cache local (apt-get clean), la prochaine installation du paquet mplayer sera la version de medibuntu ... et ainsi de suite.

vikin · Le 12/11/2009, à 17:27

Ce n'est pas le cas que j'ai voulu décrire.

Je vais essayer d'expliquer sans trop me mélanger les pinceaux.

Déjà le problème ne venait pas du cache local puisque je le paramètre pour qu'il se vide après installation.

J'avais installé 3 ou 4 dépôts.
Le premier a modifié le logiciel puis la dépendances X.
Le second avait besoin de la dépendances X. Comme elle était déjà modifié, il ne l'a pas fait.
Mais comme il avait besoin de la dépendances Y il l'a modifié.

Et ainsi de suite avec les autres dépôts.
Les dépendances X, Y et Z n'étaient réellement reliées entre elles que par les logiciels installés, mais elles étaient reliées à d'autres paquets plus important du système.

La suppression des dépôts les a donc déplacé dans une autre catégorie dans origine.
La désinstallation des logiciels s'est passé sans encombre mais les dépendances X, Y et Z qui restaient utilisées par d'autres paquets sont restées.
Même après un aptitude purge `dpkg -l | grep......... puisque le système en avait besoin elles ne sont pas apparues dans la liste.

Ces dépendances étant plus récentes les mises à jour ne se sont pas faites. Impactant de par la même sur deux ou trois autres dépendances.
Certes elles étaient plus récentes mais cela n'en fait pas un gage de sécurité et lors d'une mise à jour on ne passe pas forcement sur une version supérieure.

Exemple : Openoffice.

Dans mon cas j'ai du supprimer près de 150 paquets dont certains étaient liés à Gnome-panel et Nautilus.

Tout ça pour dire qu'une restauration via Synaptic dans certains cas, risque d'être folklorique.

xabilon · Le 12/11/2009, à 20:11

En fait, ce qu'il faudrait c'est que :
- les dépôts PPA se basent le plus possible sur les versions des dépendances des dépôts officiels.
- éventuellement utiliser un fichier preferences pour APT, de façon a ce que les dépôts officiels aient toujours la priorité sur les non-officiels.
- et se mettre bien dans la tête que les PPA ne sont pas des dépôts officiels.

Pour "annuler" une installation par PPA qui aurait installé des dépendances non présentes sur les dépôts officiels, il faut utiliser systématiquement aptitude ou l'option "autoremove" de apt-get

Pour annuler une installation par PPA qui aurait upgradé des paquets dans des versions non présentes sur les dépôts officiel (donc les downgrader), je crois qu'il n'y a rien de prévu dans APT.

draco31.fr · Le 12/11/2009, à 21:00

xabilon a écrit :

Pour annuler une installation par PPA qui aurait upgradé des paquets dans des versions non présentes sur les dépôts officiel (donc les downgrader), je crois qu'il n'y a rien de prévu dans APT.

Peut-être qu'un apt-get install --reinstall après avoir retirer le PPA de la liste des dépôts permet de repartir de la version des dépôts officiels (en supposant que le cache soit vide).

Je ne connais pas bien tout les options de apt-get, mais j'ai repéré celle-ci dessous qui pourrait servir :

--no-upgrade
Aucune mise à niveau ; quand elle est utilisée avec install, cette
commande empêche les paquets listés sur la ligne de commande d´être
mis à niveau. Élément de configuration : APT::Get::Upgrade.
-u, --show-upgraded
Afficher les paquets mis à niveau ; affiche une liste de tous les
paquets à mettre à niveau. Élément de configuration :
APT::Get::Show-Upgraded.
--print-uris
Au lieu d´aller chercher les paquets à installer, leurs URI sont
affichées. Chaque URI a un chemin, un nom de fichier destination,
une taille et une clé md5 attendue. Notez que le nom de fichier à
afficher ne correspond pas toujours au nom de fichier sur le site
distant ! Cette option fonctionne aussi avec la commande source et
avec la commande update. Avec la commande update, la somme MD5 et
la taille ne sont pas données et c´est à l´utilisateur de
décompresser les fichiers compressés. Élément de configuration :
APT::Get::Print-URIs.

Avec tout ça, on devrait pouvoir contrôler que l'installation d'un paquet ne pas d'autre dépendances à jour, ou au moins de contrôler d'où il prendra la mise à jour !

vikin · Le 12/11/2009, à 21:28

Ubuntosaure proposait sur son blog une commande qui consistait à sauvegarder la liste des paquets installés pour pouvoir la réinstaller facilement dans son intégralité en une seule manipulation.

Peut être utile dans les cas de modifications extrêmes.

Sauvegarder et restaurer les paquets installés:
dpkg --get-selections > selections.txt
La commande va récupérer la liste de tous les paquets dans le fichier selections.txt qui sera placé dans votre dossier personnel.
Pour restaurer les paquets:
dpkg --set-selections < selections.txt && sudo apt-get dselect-upgrade

Dernière modification par vikin (Le 12/11/2009, à 21:30)

psychederic · Le 12/11/2009, à 23:10

La seule solution pour installer des choses et ne pas casser le merveilleux et parfait système linux ( qui a était très bien pensé d'ailleur ) ca serait des paquets "portables" ou virtualisé.
http://doc.ubuntu-fr.org/logiciels_portables_et_virtualisation_d_applications

BIensur ca prendrait plus de place si on mettait en place un dépôt de paquet de ce genre : mais on pourrait installer sans risque : et ca serait compatible tout linux ( et si c'est pas compatible pour quelque , ca n'impacterait pas le système).

( ce qu'apparament la linuxfondation est en train de normaliser http://ldn.linuxfoundation.org/lsb/make-your-app-portable

mais vous allez me dire c'est quoi la linux fondation fasse à l'avis d'un geek monsieur je sait tout avec son avis tout fait).

Dernière modification par psychederic (Le 12/11/2009, à 23:12)

draco31.fr · Le 13/11/2009, à 00:21

@ Vikin,
Je ne crois pas que la solution de Ubuntosaure permette de restaurer un paquet mis à jour.
De plus, je ne pense pas que cela désinstalle les nouveaux paquets ajoutés entre temps.
Cela dit, c'est une solution pour celui ou celle qui veut retrouver son système quasi fonctionnel après une réinstallation.

Une autre solution serait de compiler les logiciels depuis les sources avec les librairies en statique intégrée au binaire... mais cela fait fortement grossir la taille du bin !!!

@ Psychederic
Je ne connais pas le principe des paquets portables, peux-tu nous indiquer en quoi cela résoudrait le problème posé ici ?
(J'ai lu la doc mais j'ai pas compris le but de telle application, si ce n'est pour la sécurité entreprises)

NB : J'ai vu les révisions de la page, et vu le nombre en si peu de temps, je te conseille d'utiliser le bonton "Aperçu" avant de sauver la page : cela évitera de spamer la boite des admins du wiki à chaque validation de la page :-)

psychederic · Le 13/11/2009, à 00:32

@draco

Oui c'est vrai je fais beaucoup de révision , là c'est vraiment quasiment nouveau pour le monde linux.

Le principe serait d'empaqueter un logiciel, donc le binaire et ces dépendances.

Et de l'executer dans son propre environnement avec ses libraries. ( que tu ais ou non les librairies dans ton système ne pose plus de problème, et ca ne vient pas toucher DU TOUT à ton système : tu pourrais avoir ubuntu 6.06 et lancer firefox 3.5)

L'application est coupé du système ( le plus possible ). Les paramètres de configuration sont sauvés dans un sous dossier.

Il faut tout de même un kernel linux pour l'executer et le bureau gnome par exemple. ( on ne fait pas toutes les dépendances , cela reviendrait à faire un live cd).

DOnc avec ce principe tu peux te promener avec ton application sur ta clés, et aller chez des amis, ( ou pour les étudiants sur leurs pc de l'école).

Je pense que le cas de l'entreprise tu l'as bien compris.

Donc si tu veux tu peux essayer une des applications portable sur ce site.

http://www.portools.com/apps

Ma proposition c'est justement de faire du linux natif ( et pas une solution klik de kde) : et pourquoi pas intégrer ça dans un dépôts. ( qui fonctionnerait pour toute distribution ).

Dernière modification par psychederic (Le 13/11/2009, à 00:47)

draco31.fr · Le 13/11/2009, à 14:53

psychederic a écrit :

Donc avec ce principe tu peux te promener avec ton application sur ta clés, et aller chez des amis, ( ou pour les étudiants sur leurs pc de l'école).

Le point faible de ce système est qu'il faut disposer d'un parc informatique avec un noyau linux d'installé.
Dans le même genre, la FramaKey qui embarque des logiciels portables pour Windows, rencontre un vif succès du fait de l'étendu du parc informatique des PC sous Windows.
Personnellement, j'aurai beaucoup de mal à trouver dans mon entourage des personnes sous GNU/Linux.

Autre remarque, moi qui suis sur architecture 64 bits, est-ce que cela impacte les logiciels portables ?
Je ne crois pas pouvoir faire tourner une appli 64 bits chez mon voisin en kernel 32 bits ?!

Dernière modification par draco31.fr (Le 13/11/2009, à 14:54)

psychederic · Le 13/11/2009, à 15:26

@draco

Personnellement, j'aurai beaucoup de mal à trouver dans mon entourage des personnes sous GNU/Linux.

@oui bien sur pour une utilisation personnel, et si y a personne qui a du linux ou tu vas. IL y a des cybercafé avec du linux.

Donc oui c'est sur un appli portable linux a besoin de linux, sinon tu prend ton live cd ou live usb.

Je ne crois pas pouvoir faire tourner une appli 64 bits chez mon voisin en kernel 32 bits ?!

Oui biensur pareil sous windows. Mais tu peux faire l'inverse ( et tu sais qu'au niveau perf 32/64- c'est pas très diffèrent ?)

EN TOUT cas ca ne foutrais pas en l'air le système : et on pourrait "installer" (executer ) des applis en se prenant moins la tête et en se disant : est ce que ca va encore casser des dépendances, (en terme professionnel : quels sont les impactes).

Vous remarquez aussi que les paquets dans les dépots ne sont pas forcément tous "bon" et exécutable, car pas essayé avec les nouvelles librairies de la nouvelle version d'ubuntu. ( en tout cas ca m'est déjà arrivé )

Dernière modification par psychederic (Le 13/11/2009, à 17:53)

draco31.fr · Le 13/11/2009, à 20:43

Pour ne pas avoir de surprise, j'utilise une LiveUSB persistant.
Comme ça, que le PC sur lequel je souhaite bosser soit sous Win ou Linux, je me pose pas la question : il me suffit de booter sur ma clé USB.
Cela dit, j'espère bien qu'un jour j'aurai plus de faciliter à trouver un PC sous Gnu/Linux que sous Windows (Je travaille déjà activement mon entourage pour les faire migrer en douceur).

Pour le problème 32/64 bits, je ne peux pas exécuter d'appli compilée en 32 bits sur mon système 64 bits sans installer les paquets lib32 (ou ia32-*).
Je pense que si les appli portables dont tu parles devait intégrer toutes ces lib, elles seraient vraiment énorme, donc je doute que TOUTES les libs 32 bits soit intégrée aux applis portables 32 bits... mais vu que la question me titille, je vais potasser tes liens un peu plus en détail pour voir par moi même

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 12/11/2009, à 08:10

annuler une installation via PPA ?

#2 Le 12/11/2009, à 08:17

Re : annuler une installation via PPA ?

#3 Le 12/11/2009, à 09:02

Re : annuler une installation via PPA ?

#4 Le 12/11/2009, à 09:21

Re : annuler une installation via PPA ?

#5 Le 12/11/2009, à 09:37

Re : annuler une installation via PPA ?

#6 Le 12/11/2009, à 10:01

Re : annuler une installation via PPA ?

#7 Le 12/11/2009, à 10:23

Re : annuler une installation via PPA ?

#8 Le 12/11/2009, à 14:15

Re : annuler une installation via PPA ?

#9 Le 12/11/2009, à 17:27

Re : annuler une installation via PPA ?

#10 Le 12/11/2009, à 20:11

Re : annuler une installation via PPA ?

#11 Le 12/11/2009, à 21:00

Re : annuler une installation via PPA ?

#12 Le 12/11/2009, à 21:28

Re : annuler une installation via PPA ?

#13 Le 12/11/2009, à 23:10

Re : annuler une installation via PPA ?

#14 Le 13/11/2009, à 00:21

Re : annuler une installation via PPA ?

#15 Le 13/11/2009, à 00:32

Re : annuler une installation via PPA ?

#16 Le 13/11/2009, à 14:53

Re : annuler une installation via PPA ?

#17 Le 13/11/2009, à 15:26

Re : annuler une installation via PPA ?

#18 Le 13/11/2009, à 20:43

Re : annuler une installation via PPA ?

Pied de page des forums