@Alexandre : j'ai un peu peur d'aller plus avant dans la procédure de
changement de version. J'avais lu aussi la recommandation concernant
apt, maintenant passer d'une méthode à l'autre n'est peut-être pas sans
surprises sur l'arbre des dépendances (à l'image des désagréments que
causeraient [? j'en sais rien en fait...] l'utilisation alternative de
apt-get et aptitude) ;
@Nicolas : oui, j'oublie de préciser dans mon message que c'est bien
vers /usr/bin/python3.4 que pointe le raccourci python3. À ton avis,
est-ce que cela relèverait d'un bricolage scabreux de changer
provisoirement le lien symbolique vers /usr/bin/python3.2 ?
@Maderios : la suppression du paquet requiert de supprimer un grand
nombre d'autres, cela m'effraie, et surtout je n'aurai guère le temps de
me lancer là-dedans. Dans cet ordre d'idée j'ai essayé de faire une
réinstallation du paquet (avec apt-get et l'option --reinstall), sans
succès.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
nicolas.patrois
Le 19/07/2017 13:50:13, Vincent Bain a écrit :
@Nicolas : oui, j'oublie de préciser dans mon message que c'est bien vers /usr/bin/python3.4 que pointe le raccourci python3. À ton avis, est-ce que cela relèverait d'un bricolage scabreux de changer provisoirement le lien symbolique vers /usr/bin/python3.2 ?
Ça ne me semble pas scabreux mais avant de tripoter le lien symbolique , vérifie s’il n’est pas déjà géré via update-alternatives. nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait... =
Le 19/07/2017 13:50:13, Vincent Bain a écrit :
@Nicolas : oui, j'oublie de préciser dans mon message que c'est bien
vers /usr/bin/python3.4 que pointe le raccourci python3. À ton avis,
est-ce que cela relèverait d'un bricolage scabreux de changer
provisoirement le lien symbolique vers /usr/bin/python3.2 ?
Ça ne me semble pas scabreux mais avant de tripoter le lien symbolique , vérifie s’il n’est pas déjà géré via update-alternatives.
nicolas patrois : pts noir asocial
--
RÉALISME
M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...
=
@Nicolas : oui, j'oublie de préciser dans mon message que c'est bien vers /usr/bin/python3.4 que pointe le raccourci python3. À ton avis, est-ce que cela relèverait d'un bricolage scabreux de changer provisoirement le lien symbolique vers /usr/bin/python3.2 ?
Ça ne me semble pas scabreux mais avant de tripoter le lien symbolique , vérifie s’il n’est pas déjà géré via update-alternatives. nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait... =
Vincent Bain
Le mercredi 19 juillet 2017 à 17:57 +0200, a écrit :
Ça ne me semble pas scabreux mais avant de tripoter le lien symbolique, vérifie s’il n’est pas déjà géré via update-alternatives.
malheureusement pas pris en charge ;-( # update-alternatives --list python3 update-alternatives: erreur: pas d'alternatives pour python3 Si je tente de faire update-alternatives --install ... je ne sais pas bien comment gérer les priorités ; dans mon cas il faudrait une priorité 2 sur /usr/bin/python3.2 et 1 sur /usr/bin/python3.4. faut-il craindre des conséquences dommageables par ailleurs suite à ce choix ? Bon, le mieux est sans doute d'essayer... Merci pour ta suggestion. Vincent.
Le mercredi 19 juillet 2017 à 17:57 +0200, nicolas.patrois@gmail.com a
écrit :
Ça ne me semble pas scabreux mais avant de tripoter le lien symbolique, vérifie s’il n’est pas déjà géré via update-alternatives.
malheureusement pas pris en charge ;-(
# update-alternatives --list python3
update-alternatives: erreur: pas d'alternatives pour python3
Si je tente de faire update-alternatives --install ... je ne sais pas
bien comment gérer les priorités ; dans mon cas il faudrait une priorité
2 sur /usr/bin/python3.2 et 1 sur /usr/bin/python3.4. faut-il craindre
des conséquences dommageables par ailleurs suite à ce choix ?
Bon, le mieux est sans doute d'essayer...
Merci pour ta suggestion.
Le mercredi 19 juillet 2017 à 17:57 +0200, a écrit :
Ça ne me semble pas scabreux mais avant de tripoter le lien symbolique, vérifie s’il n’est pas déjà géré via update-alternatives.
malheureusement pas pris en charge ;-( # update-alternatives --list python3 update-alternatives: erreur: pas d'alternatives pour python3 Si je tente de faire update-alternatives --install ... je ne sais pas bien comment gérer les priorités ; dans mon cas il faudrait une priorité 2 sur /usr/bin/python3.2 et 1 sur /usr/bin/python3.4. faut-il craindre des conséquences dommageables par ailleurs suite à ce choix ? Bon, le mieux est sans doute d'essayer... Merci pour ta suggestion. Vincent.
nicolas.patrois
Le 19/07/2017 18:11:04, Vincent Bain a écrit :
Le mercredi 19 juillet 2017 à 17:57 +0200, a écrit :
Ça ne me semble pas scabreux mais avant de tripoter le lien
symbolique, vérifie s’il n’est pas déjà g éré via update-alternatives. malheureusement pas pris en charge ;-(
Alors tu le fais à la main. nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait... =
Le 19/07/2017 18:11:04, Vincent Bain a écrit :
Le mercredi 19 juillet 2017 à 17:57 +0200, nicolas.patrois@gmail.com a
écrit :
> Ça ne me semble pas scabreux mais avant de tripoter le lien
symbolique, vérifie s’il n’est pas déjà g éré via update-alternatives.
malheureusement pas pris en charge ;-(
Alors tu le fais à la main.
nicolas patrois : pts noir asocial
--
RÉALISME
M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...
=
Le mercredi 19 juillet 2017 à 17:57 +0200, a écrit :
Ça ne me semble pas scabreux mais avant de tripoter le lien
symbolique, vérifie s’il n’est pas déjà g éré via update-alternatives. malheureusement pas pris en charge ;-(
Alors tu le fais à la main. nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait... =
Alexandre Hoïde
On Wed, Jul 19, 2017 at 01:50:13PM +0200, Vincent Bain wrote:
@Alexandre : j'ai un peu peur d'aller plus avant dans la procédure de changement de version.
De quoi ? De Python, de Debian, ou des deux ? ;) Si tu parles de Debian, à ta place, j'essaierais également de résoudre les problèmes avant de passer à Stretch. Si tu parles de Python, tu peux toujours voir ce que donnerait un « apt-get dist-upgrade » en lui ajoutant l'option « --simulate » : sans risque !
J'avais lu aussi la recommandation concernant apt, maintenant passer d'une méthode à l'autre n'est peut-être pas sans surprises sur l'arbre des dépendances (à l'image des désagréments que causeraient [? j'en sais rien en fait...] l'utilisation alternative de apt-get et aptitude) ;
Dans certains cas, il peut arriver que aptitude propose des suppressions massives de paquets pour résoudre des conflits et/ou dépendances manquantes. Mais tu peux te fier à apt-get sous Jessie et à apt sous Stretch. -- ___________________ | $ post_tenebras ↲ | waouh! | GNU / | | -- * -- | o | $ who ↲ / |_-- ~_| | Alexandre Hoïde | _/| | -------------------
On Wed, Jul 19, 2017 at 01:50:13PM +0200, Vincent Bain wrote:
@Alexandre : j'ai un peu peur d'aller plus avant dans la procédure de
changement de version.
De quoi ? De Python, de Debian, ou des deux ? ;) Si tu parles de
Debian, à ta place, j'essaierais également de résoudre les problèmes
avant de passer à Stretch. Si tu parles de Python, tu peux toujours voir
ce que donnerait un « apt-get dist-upgrade » en lui ajoutant l'option
« --simulate » : sans risque !
J'avais lu aussi la recommandation concernant apt, maintenant passer
d'une méthode à l'autre n'est peut-être pas sans surprises sur l'arbre
des dépendances (à l'image des désagréments que causeraient [? j'en
sais rien en fait...] l'utilisation alternative de apt-get et
aptitude) ;
Dans certains cas, il peut arriver que aptitude propose des
suppressions massives de paquets pour résoudre des conflits et/ou
dépendances manquantes. Mais tu peux te fier à apt-get sous Jessie et à
apt sous Stretch.
On Wed, Jul 19, 2017 at 01:50:13PM +0200, Vincent Bain wrote:
@Alexandre : j'ai un peu peur d'aller plus avant dans la procédure de changement de version.
De quoi ? De Python, de Debian, ou des deux ? ;) Si tu parles de Debian, à ta place, j'essaierais également de résoudre les problèmes avant de passer à Stretch. Si tu parles de Python, tu peux toujours voir ce que donnerait un « apt-get dist-upgrade » en lui ajoutant l'option « --simulate » : sans risque !
J'avais lu aussi la recommandation concernant apt, maintenant passer d'une méthode à l'autre n'est peut-être pas sans surprises sur l'arbre des dépendances (à l'image des désagréments que causeraient [? j'en sais rien en fait...] l'utilisation alternative de apt-get et aptitude) ;
Dans certains cas, il peut arriver que aptitude propose des suppressions massives de paquets pour résoudre des conflits et/ou dépendances manquantes. Mais tu peux te fier à apt-get sous Jessie et à apt sous Stretch. -- ___________________ | $ post_tenebras ↲ | waouh! | GNU / | | -- * -- | o | $ who ↲ / |_-- ~_| | Alexandre Hoïde | _/| | -------------------
Vincent Bain
Le mercredi 19 juillet 2017 à 21:44 +0200, Alexandre Hoïde a écrit :
De quoi ? De Python, de Debian, ou des deux ? ;) Si tu parles de Debian, à ta place, j'essaierais également de résoudre les problèmes avant de passer à Stretch. Si tu parles de Python, tu peux toujours voir ce que donnerait un « apt-get dist-upgrade » en lui ajoutant l'option « --simulate » : sans risque !
j'ai pas mal de programmes compilés à la main, c'est toujours mieux si la migration se fait sans pépins... # apt-get dist-upgrade --simulate [...] 0 mis à jour, 0 nouvellement installés, 0 à enlever et 1 non mis à jour. 5 partiellement installés ou enlevés. Conf python3.4-minimal (3.4.2-1 Debian:8.8/oldstable [amd64]) Conf python3-minimal (3.4.2-2 Debian:8.8/oldstable [amd64]) Conf python3 (3.4.2-2 Debian:8.8/oldstable [amd64]) Conf gnome-menus (3.13.3-6 Debian:8.8/oldstable [amd64]) Conf python3-pykcs11 (1.3.0-1 Debian:8.8/oldstable [amd64]) Je vais terminer mes sauvegardes et me lancer...
Dans certains cas, il peut arriver que aptitude propose des suppressions massives de paquets pour résoudre des conflits et/ou dépendances manquantes. Mais tu peux te fier à apt-get sous Jessie et à apt sous Stretch.
apt-get me sort aussi toujours une liste de paquets soi-disant bons à supprimer, parmi lesquels un tas de choses qui me sont très utiles...
Le mercredi 19 juillet 2017 à 21:44 +0200, Alexandre Hoïde a écrit :
De quoi ? De Python, de Debian, ou des deux ? ;) Si tu parles de
Debian, à ta place, j'essaierais également de résoudre les problèmes
avant de passer à Stretch. Si tu parles de Python, tu peux toujours voir
ce que donnerait un « apt-get dist-upgrade » en lui ajoutant l'option
« --simulate » : sans risque !
j'ai pas mal de programmes compilés à la main, c'est toujours mieux si
la migration se fait sans pépins...
# apt-get dist-upgrade --simulate
[...]
0 mis à jour, 0 nouvellement installés, 0 à enlever et 1 non mis à jour.
5 partiellement installés ou enlevés.
Conf python3.4-minimal (3.4.2-1 Debian:8.8/oldstable [amd64])
Conf python3-minimal (3.4.2-2 Debian:8.8/oldstable [amd64])
Conf python3 (3.4.2-2 Debian:8.8/oldstable [amd64])
Conf gnome-menus (3.13.3-6 Debian:8.8/oldstable [amd64])
Conf python3-pykcs11 (1.3.0-1 Debian:8.8/oldstable [amd64])
Je vais terminer mes sauvegardes et me lancer...
Dans certains cas, il peut arriver que aptitude propose des
suppressions massives de paquets pour résoudre des conflits et/ou
dépendances manquantes. Mais tu peux te fier à apt-get sous Jessie et à
apt sous Stretch.
apt-get me sort aussi toujours une liste de paquets soi-disant bons à
supprimer, parmi lesquels un tas de choses qui me sont très utiles...
Le mercredi 19 juillet 2017 à 21:44 +0200, Alexandre Hoïde a écrit :
De quoi ? De Python, de Debian, ou des deux ? ;) Si tu parles de Debian, à ta place, j'essaierais également de résoudre les problèmes avant de passer à Stretch. Si tu parles de Python, tu peux toujours voir ce que donnerait un « apt-get dist-upgrade » en lui ajoutant l'option « --simulate » : sans risque !
j'ai pas mal de programmes compilés à la main, c'est toujours mieux si la migration se fait sans pépins... # apt-get dist-upgrade --simulate [...] 0 mis à jour, 0 nouvellement installés, 0 à enlever et 1 non mis à jour. 5 partiellement installés ou enlevés. Conf python3.4-minimal (3.4.2-1 Debian:8.8/oldstable [amd64]) Conf python3-minimal (3.4.2-2 Debian:8.8/oldstable [amd64]) Conf python3 (3.4.2-2 Debian:8.8/oldstable [amd64]) Conf gnome-menus (3.13.3-6 Debian:8.8/oldstable [amd64]) Conf python3-pykcs11 (1.3.0-1 Debian:8.8/oldstable [amd64]) Je vais terminer mes sauvegardes et me lancer...
Dans certains cas, il peut arriver que aptitude propose des suppressions massives de paquets pour résoudre des conflits et/ou dépendances manquantes. Mais tu peux te fier à apt-get sous Jessie et à apt sous Stretch.
apt-get me sort aussi toujours une liste de paquets soi-disant bons à supprimer, parmi lesquels un tas de choses qui me sont très utiles...
Alexandre Hoïde
On Thu, Jul 20, 2017 at 08:57:14AM +0200, Vincent Bain wrote:
Le mercredi 19 juillet 2017 à 21:44 +0200, Alexandre Hoïde a écrit :
De quoi ? De Python, de Debian, ou des deux ? ;) Si tu parles de Debian, à ta place, j'essaierais également de résoudre les problèmes avant de passer à Stretch. Si tu parles de Python, tu peux toujours voir ce que donnerait un « apt-get dist-upgrade » en lui ajoutant l'option « --simulate » : sans risque !
j'ai pas mal de programmes compilés à la main, c'est toujours mieux si la migration se fait sans pépins...
Pour sûr.
# apt-get dist-upgrade --simulate [...] 0 mis à jour, 0 nouvellement installés, 0 à enlever et 1 non mis à jour. 5 partiellement installés ou enlevés. Conf python3.4-minimal (3.4.2-1 Debian:8.8/oldstable [amd64]) Conf python3-minimal (3.4.2-2 Debian:8.8/oldstable [amd64]) Conf python3 (3.4.2-2 Debian:8.8/oldstable [amd64]) Conf gnome-menus (3.13.3-6 Debian:8.8/oldstable [amd64]) Conf python3-pykcs11 (1.3.0-1 Debian:8.8/oldstable [amd64]) Je vais terminer mes sauvegardes et me lancer...
Ça confirme un peu c'que j'avais dans l'idée.
Dans certains cas, il peut arriver que aptitude propose des suppressions massives de paquets pour résoudre des conflits et/ou dépendances manquantes. Mais tu peux te fier à apt-get sous Jessie et à apt sous Stretch.
apt-get me sort aussi toujours une liste de paquets soi-disant bons à supprimer, parmi lesquels un tas de choses qui me sont très utiles...
Peut-être le sais-tu déjà, sinon : SI ces paquets -- qui te sont très utiles -- 1. ont été installés automatiquement (marqués « auto-installed ») * tu peux le vérifier de plusieurs manières, dont « apt-mark » et « aptitude » ET QUE 2. le paquet ayant déclenché leur installation, par [cascade de] dépendances a été supprimé par la suite ALORS 3. il est normal que apt-get t'en propose la suppression à chaque upgrade. Dans ce cas, il est possible de changer le marquage des paquets que l'on souhaite conserver à l'aide de « aptitude » ou de « apt-mark ». Ces deux logiciels utilisent les mêmes données stockées dans « /var/lib/apt/extended_states ». -- ___________________ | $ post_tenebras ↲ | waouh! | GNU / | | -- * -- | o | $ who ↲ / |_-- ~_| | Alexandre Hoïde | _/| | -------------------
On Thu, Jul 20, 2017 at 08:57:14AM +0200, Vincent Bain wrote:
Le mercredi 19 juillet 2017 à 21:44 +0200, Alexandre Hoïde a écrit :
> De quoi ? De Python, de Debian, ou des deux ? ;) Si tu parles de
> Debian, à ta place, j'essaierais également de résoudre les problèmes
> avant de passer à Stretch. Si tu parles de Python, tu peux toujours voir
> ce que donnerait un « apt-get dist-upgrade » en lui ajoutant l'option
> « --simulate » : sans risque !
j'ai pas mal de programmes compilés à la main, c'est toujours mieux si
la migration se fait sans pépins...
Pour sûr.
# apt-get dist-upgrade --simulate
[...]
0 mis à jour, 0 nouvellement installés, 0 à enlever et 1 non mis à jour.
5 partiellement installés ou enlevés.
Conf python3.4-minimal (3.4.2-1 Debian:8.8/oldstable [amd64])
Conf python3-minimal (3.4.2-2 Debian:8.8/oldstable [amd64])
Conf python3 (3.4.2-2 Debian:8.8/oldstable [amd64])
Conf gnome-menus (3.13.3-6 Debian:8.8/oldstable [amd64])
Conf python3-pykcs11 (1.3.0-1 Debian:8.8/oldstable [amd64])
Je vais terminer mes sauvegardes et me lancer...
Ça confirme un peu c'que j'avais dans l'idée.
> Dans certains cas, il peut arriver que aptitude propose des
> suppressions massives de paquets pour résoudre des conflits et/ou
> dépendances manquantes. Mais tu peux te fier à apt-get sous Jessie et à
> apt sous Stretch.
apt-get me sort aussi toujours une liste de paquets soi-disant bons à
supprimer, parmi lesquels un tas de choses qui me sont très utiles...
Peut-être le sais-tu déjà, sinon :
SI ces paquets -- qui te sont très utiles --
1. ont été installés automatiquement (marqués « auto-installed »)
* tu peux le vérifier de plusieurs manières, dont « apt-mark » et
« aptitude »
ET QUE
2. le paquet ayant déclenché leur installation, par [cascade de]
dépendances a été supprimé par la suite
ALORS
3. il est normal que apt-get t'en propose la suppression à chaque
upgrade.
Dans ce cas, il est possible de changer le marquage des paquets que
l'on souhaite conserver à l'aide de « aptitude » ou de « apt-mark ». Ces
deux logiciels utilisent les mêmes données stockées dans
« /var/lib/apt/extended_states ».
On Thu, Jul 20, 2017 at 08:57:14AM +0200, Vincent Bain wrote:
Le mercredi 19 juillet 2017 à 21:44 +0200, Alexandre Hoïde a écrit :
De quoi ? De Python, de Debian, ou des deux ? ;) Si tu parles de Debian, à ta place, j'essaierais également de résoudre les problèmes avant de passer à Stretch. Si tu parles de Python, tu peux toujours voir ce que donnerait un « apt-get dist-upgrade » en lui ajoutant l'option « --simulate » : sans risque !
j'ai pas mal de programmes compilés à la main, c'est toujours mieux si la migration se fait sans pépins...
Pour sûr.
# apt-get dist-upgrade --simulate [...] 0 mis à jour, 0 nouvellement installés, 0 à enlever et 1 non mis à jour. 5 partiellement installés ou enlevés. Conf python3.4-minimal (3.4.2-1 Debian:8.8/oldstable [amd64]) Conf python3-minimal (3.4.2-2 Debian:8.8/oldstable [amd64]) Conf python3 (3.4.2-2 Debian:8.8/oldstable [amd64]) Conf gnome-menus (3.13.3-6 Debian:8.8/oldstable [amd64]) Conf python3-pykcs11 (1.3.0-1 Debian:8.8/oldstable [amd64]) Je vais terminer mes sauvegardes et me lancer...
Ça confirme un peu c'que j'avais dans l'idée.
Dans certains cas, il peut arriver que aptitude propose des suppressions massives de paquets pour résoudre des conflits et/ou dépendances manquantes. Mais tu peux te fier à apt-get sous Jessie et à apt sous Stretch.
apt-get me sort aussi toujours une liste de paquets soi-disant bons à supprimer, parmi lesquels un tas de choses qui me sont très utiles...
Peut-être le sais-tu déjà, sinon : SI ces paquets -- qui te sont très utiles -- 1. ont été installés automatiquement (marqués « auto-installed ») * tu peux le vérifier de plusieurs manières, dont « apt-mark » et « aptitude » ET QUE 2. le paquet ayant déclenché leur installation, par [cascade de] dépendances a été supprimé par la suite ALORS 3. il est normal que apt-get t'en propose la suppression à chaque upgrade. Dans ce cas, il est possible de changer le marquage des paquets que l'on souhaite conserver à l'aide de « aptitude » ou de « apt-mark ». Ces deux logiciels utilisent les mêmes données stockées dans « /var/lib/apt/extended_states ». -- ___________________ | $ post_tenebras ↲ | waouh! | GNU / | | -- * -- | o | $ who ↲ / |_-- ~_| | Alexandre Hoïde | _/| | -------------------
Vincent Bain
Le jeudi 20 juillet 2017 à 09:51 +0200, Alexandre Hoïde a écrit :
Dans ce cas, il est possible de changer le marquage des paquets que l'on souhaite conserver à l'aide de « aptitude » ou de « apt-mark ». Ces deux logiciels utilisent les mêmes données stockées dans « /var/lib/apt/extended_states ».
Ah benh non, le mécanisme de marquage m'était inconnu. Merci pour l'astuce... V.
Le jeudi 20 juillet 2017 à 09:51 +0200, Alexandre Hoïde a écrit :
Dans ce cas, il est possible de changer le marquage des paquets que
l'on souhaite conserver à l'aide de « aptitude » ou de « apt-mark ».
Ces
deux logiciels utilisent les mêmes données stockées dans
« /var/lib/apt/extended_states ».
Ah benh non, le mécanisme de marquage m'était inconnu. Merci pour
l'astuce...
Le jeudi 20 juillet 2017 à 09:51 +0200, Alexandre Hoïde a écrit :
Dans ce cas, il est possible de changer le marquage des paquets que l'on souhaite conserver à l'aide de « aptitude » ou de « apt-mark ». Ces deux logiciels utilisent les mêmes données stockées dans « /var/lib/apt/extended_states ».
Ah benh non, le mécanisme de marquage m'était inconnu. Merci pour l'astuce... V.
Alexandre Hoïde
On Sat, Jul 22, 2017 at 03:29:29PM +0200, Vincent Bain wrote:
Le jeudi 20 juillet 2017 à 09:51 +0200, Alexandre Hoïde a écrit :
SI ces paquets -- qui te sont très utiles -- 1. ont été installés automatiquement (marqués « auto-installed ») * tu peux le vérifier de plusieurs manières, dont « apt-mark » et « aptitude » ET QUE 2. le paquet ayant déclenché leur installation, par [cascade de] dépendances a été supprimé par la suite ALORS 3. il est normal que apt-get t'en propose la suppression à chaque upgrade. Dans ce cas, il est possible de changer le marquage des paquets que l'on souhaite conserver à l'aide de « aptitude » ou de « apt-mark ». Ces deux logiciels utilisent les mêmes données stockées dans « /var/lib/apt/extended_states ».
Dans ce cas, il est possible de changer le marquage des paquets que l'on souhaite conserver à l'aide de « aptitude » ou de « apt-mark ». Ces deux logiciels utilisent les mêmes données stockées dans « /var/lib/apt/extended_states ».
Ah benh non, le mécanisme de marquage m'était inconnu. Merci pour l'astuce...
Je t'en prie ! J'en profite pour corriger le point 2 :
[…] ET QUE
2. il ne reste aucun paquet installé qui dépende [in]directement des paquets marqués « auto-installed »
On Sat, Jul 22, 2017 at 03:29:29PM +0200, Vincent Bain wrote:
Le jeudi 20 juillet 2017 à 09:51 +0200, Alexandre Hoïde a écrit :
SI ces paquets -- qui te sont très utiles --
1. ont été installés automatiquement (marqués « auto-installed »)
* tu peux le vérifier de plusieurs manières, dont « apt-mark » et
« aptitude »
ET QUE
2. le paquet ayant déclenché leur installation, par [cascade de]
dépendances a été supprimé par la suite
ALORS
3. il est normal que apt-get t'en propose la suppression à chaque
upgrade.
Dans ce cas, il est possible de changer le marquage des paquets que
l'on souhaite conserver à l'aide de « aptitude » ou de « apt-mark ». Ces
deux logiciels utilisent les mêmes données stockées dans
« /var/lib/apt/extended_states ».
> Dans ce cas, il est possible de changer le marquage des paquets que
> l'on souhaite conserver à l'aide de « aptitude » ou de « apt-mark ».
> Ces
> deux logiciels utilisent les mêmes données stockées dans
> « /var/lib/apt/extended_states ».
Ah benh non, le mécanisme de marquage m'était inconnu. Merci pour
l'astuce...
Je t'en prie !
J'en profite pour corriger le point 2 :
[…] ET QUE
2. il ne reste aucun paquet installé qui dépende [in]directement des
paquets marqués « auto-installed »
On Sat, Jul 22, 2017 at 03:29:29PM +0200, Vincent Bain wrote:
Le jeudi 20 juillet 2017 à 09:51 +0200, Alexandre Hoïde a écrit :
SI ces paquets -- qui te sont très utiles -- 1. ont été installés automatiquement (marqués « auto-installed ») * tu peux le vérifier de plusieurs manières, dont « apt-mark » et « aptitude » ET QUE 2. le paquet ayant déclenché leur installation, par [cascade de] dépendances a été supprimé par la suite ALORS 3. il est normal que apt-get t'en propose la suppression à chaque upgrade. Dans ce cas, il est possible de changer le marquage des paquets que l'on souhaite conserver à l'aide de « aptitude » ou de « apt-mark ». Ces deux logiciels utilisent les mêmes données stockées dans « /var/lib/apt/extended_states ».
Dans ce cas, il est possible de changer le marquage des paquets que l'on souhaite conserver à l'aide de « aptitude » ou de « apt-mark ». Ces deux logiciels utilisent les mêmes données stockées dans « /var/lib/apt/extended_states ».
Ah benh non, le mécanisme de marquage m'était inconnu. Merci pour l'astuce...
Je t'en prie ! J'en profite pour corriger le point 2 :
[…] ET QUE
2. il ne reste aucun paquet installé qui dépende [in]directement des paquets marqués « auto-installed »
