Bonjour,
Leopold BAILLY a écrit :
L'intérêt de partir des sources est que les dépendances sont bien moins
fortes que sur le binaire. Je ne sais d'ailleurs pas pourquoi.
Je me demande même si c'est réllement justifié ( contrainte de l'éditeur de
lien ? ) ou si c'est un effet de bord de l'outil de construction de paquet qui
ne sait pas faire mieux que "photographier" les librairies utilisées lors de
la compilation.
Y aurait-il un DD dans la salle, pour éclairer ma lanterne ?
je suis pas DD mais j'peux dire que la raison de ces dépendances et que
lors de la construction d'un paquet binaire, on utilise fort logiquement
les blibliothèques partagées de la version courante (libc6 d'unstable
pour un paquet d'unstable par ex.) et la création de la liste des
dépendances plus ou moins automatique par les outils de création de
paquet associe donc la version liée au paquet construit.
ex: paquet A compilé pour unstable avec libc6 d'unstable +
lib_partagéeXYZ d'unstable
le paquet A sous forme binaire dépend de ces 2 paquets, et l'installé
tel quel sous stable/testing imposera d'installer libc6 +
lib_partagéeXYZ dans leur version d'unstable.
Parfois il s'agit de dépendances "faibles" car libc6 et lib_partagéeXYZ
dans leur version unstable n'apporte que peu de changement (correctif
d'un petit bug vicieux au fin fond d'un code peu utilisé, correctif dans
le paquet lui-même comme une page man améliorée, l'adresse de la FSF
mise à jour etc) et dans ce cas utiliser d'autres versions de ces
blibliothèques partagées est facile (ne nécéssite pas de recompilation
brute, en pratique une reconstruction du paquet est juste nécéssaire).
Dans le cas de dépendances "fortes" (interface d'une blibliothèques
modifiée, par exemple A utilise une fonction de libc6 ou lib_partagéeXYZ
appelée fonction F qui avait x paramètres avant et maintenant en à x+2
ou x-1) là c'est plus génant et il sera nécéssaire de "backporter" la
libc6/lib_partagéeXYZ d'unstable sur la version utilisée (cascade de
dépendances en perspective) ce qui explique les erreurs que l'on
rencontre parfois à la recompilation d'un paquet.
Voilà le pourquoi du comment des dépendances.
En espérant avoir éclairer tes lanternes,
Bonjour,
Leopold BAILLY a écrit :
L'intérêt de partir des sources est que les dépendances sont bien moins
fortes que sur le binaire. Je ne sais d'ailleurs pas pourquoi.
Je me demande même si c'est réllement justifié ( contrainte de l'éditeur de
lien ? ) ou si c'est un effet de bord de l'outil de construction de paquet qui
ne sait pas faire mieux que "photographier" les librairies utilisées lors de
la compilation.
Y aurait-il un DD dans la salle, pour éclairer ma lanterne ?
je suis pas DD mais j'peux dire que la raison de ces dépendances et que
lors de la construction d'un paquet binaire, on utilise fort logiquement
les blibliothèques partagées de la version courante (libc6 d'unstable
pour un paquet d'unstable par ex.) et la création de la liste des
dépendances plus ou moins automatique par les outils de création de
paquet associe donc la version liée au paquet construit.
ex: paquet A compilé pour unstable avec libc6 d'unstable +
lib_partagéeXYZ d'unstable
le paquet A sous forme binaire dépend de ces 2 paquets, et l'installé
tel quel sous stable/testing imposera d'installer libc6 +
lib_partagéeXYZ dans leur version d'unstable.
Parfois il s'agit de dépendances "faibles" car libc6 et lib_partagéeXYZ
dans leur version unstable n'apporte que peu de changement (correctif
d'un petit bug vicieux au fin fond d'un code peu utilisé, correctif dans
le paquet lui-même comme une page man améliorée, l'adresse de la FSF
mise à jour etc) et dans ce cas utiliser d'autres versions de ces
blibliothèques partagées est facile (ne nécéssite pas de recompilation
brute, en pratique une reconstruction du paquet est juste nécéssaire).
Dans le cas de dépendances "fortes" (interface d'une blibliothèques
modifiée, par exemple A utilise une fonction de libc6 ou lib_partagéeXYZ
appelée fonction F qui avait x paramètres avant et maintenant en à x+2
ou x-1) là c'est plus génant et il sera nécéssaire de "backporter" la
libc6/lib_partagéeXYZ d'unstable sur la version utilisée (cascade de
dépendances en perspective) ce qui explique les erreurs que l'on
rencontre parfois à la recompilation d'un paquet.
Voilà le pourquoi du comment des dépendances.
En espérant avoir éclairer tes lanternes,
Bonjour,
Leopold BAILLY a écrit :
L'intérêt de partir des sources est que les dépendances sont bien moins
fortes que sur le binaire. Je ne sais d'ailleurs pas pourquoi.
Je me demande même si c'est réllement justifié ( contrainte de l'éditeur de
lien ? ) ou si c'est un effet de bord de l'outil de construction de paquet qui
ne sait pas faire mieux que "photographier" les librairies utilisées lors de
la compilation.
Y aurait-il un DD dans la salle, pour éclairer ma lanterne ?
je suis pas DD mais j'peux dire que la raison de ces dépendances et que
lors de la construction d'un paquet binaire, on utilise fort logiquement
les blibliothèques partagées de la version courante (libc6 d'unstable
pour un paquet d'unstable par ex.) et la création de la liste des
dépendances plus ou moins automatique par les outils de création de
paquet associe donc la version liée au paquet construit.
ex: paquet A compilé pour unstable avec libc6 d'unstable +
lib_partagéeXYZ d'unstable
le paquet A sous forme binaire dépend de ces 2 paquets, et l'installé
tel quel sous stable/testing imposera d'installer libc6 +
lib_partagéeXYZ dans leur version d'unstable.
Parfois il s'agit de dépendances "faibles" car libc6 et lib_partagéeXYZ
dans leur version unstable n'apporte que peu de changement (correctif
d'un petit bug vicieux au fin fond d'un code peu utilisé, correctif dans
le paquet lui-même comme une page man améliorée, l'adresse de la FSF
mise à jour etc) et dans ce cas utiliser d'autres versions de ces
blibliothèques partagées est facile (ne nécéssite pas de recompilation
brute, en pratique une reconstruction du paquet est juste nécéssaire).
Dans le cas de dépendances "fortes" (interface d'une blibliothèques
modifiée, par exemple A utilise une fonction de libc6 ou lib_partagéeXYZ
appelée fonction F qui avait x paramètres avant et maintenant en à x+2
ou x-1) là c'est plus génant et il sera nécéssaire de "backporter" la
libc6/lib_partagéeXYZ d'unstable sur la version utilisée (cascade de
dépendances en perspective) ce qui explique les erreurs que l'on
rencontre parfois à la recompilation d'un paquet.
Voilà le pourquoi du comment des dépendances.
En espérant avoir éclairer tes lanternes,
Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :J'ai profité d'un récent fil pour me mettre à aptitude qui est plus
puissant de ce côté là. Il distingue les paquets installés explicitement
de ceux installés implicitement.
Pour ça, il faut d'abord initialiser la base de données en se tapant tous
les paquets un à un. On commence par tout marquer "automatique" (M) (on
peut le faire sur une branche entière), puis on marque en "manuel" (m) les
paquets de plus haut niveau que l'on souhaite garder.
[...]T'es sur qu'il y a un interet a tyous les mettre en auto au debut?
J m'explique.
J'ai lancé un apt-get update && apt-getupgrade, et donc il m'a dit la liste de
s paqets a mettre a jour.
Je n'ai pas lancé la maj.
Puis j'ai lancé, un aptitude update && a^titude upgrade, et là, il m'a
affiché, les mm paquets qu'avec apt, à mettre à jour, j'ai pas accepté non
plus, pour ne pas enregistrer d'actions dans aptitude, tant que je suis pas
sur qu'il soit bien configuré.
Donc vu qu'aptitude savait deja les bons paquets à mettre à jour, je
comprends pas pkoi il faut mettre tous les paquets en auto au depart lol ?
Pour qu'il soit en mesure de virer des le depart les paquets inutiles? (cad
non utilisés par des paquets marqués "m")
C'est ça, le faire pour tous au début permet de faire un grand ménage. Par la
suite, c'est automatique.
Je viens encore de le vérifier sur la compilation d'un paquet de sid :
apt-get build-dep m'a installé plein de paquets qui ont été automatiquement
enlevés par aptitude dist-upgrade.
Salut,
J'ai essayé, mais finalement, je me sens pas le courage de tout recocher.
Je pense que je prefere l'utiliser en supposant que mnt tout st nikel
,et qu'il y a rien à virer lol.
Le pb, c'est qu'après avoir tout mis en auto, j'avais lancé un pgrade
pour voir, d'ou la grande liste de suppression, j'ai refusé.
J'ai relanc& aptitude, j'ai tout remis en manuel, et malgrès cela, il
veut tjs tout me supprimer...:-(
Une idee, pour le remettre dans son etat initial?
Pq si je remets tout en manuel comme avant, y'a pas de raison, qu'il
veuille tout me virer non?
Leopold BAILLY a écrit :
Thierry B <debian@thierry.eu.org> writes:
Leopold BAILLY a écrit :
Thierry B <debian@thierry.eu.org> writes:
Leopold BAILLY a écrit :
J'ai profité d'un récent fil pour me mettre à aptitude qui est plus
puissant de ce côté là. Il distingue les paquets installés explicitement
de ceux installés implicitement.
Pour ça, il faut d'abord initialiser la base de données en se tapant tous
les paquets un à un. On commence par tout marquer "automatique" (M) (on
peut le faire sur une branche entière), puis on marque en "manuel" (m) les
paquets de plus haut niveau que l'on souhaite garder.
[...]
T'es sur qu'il y a un interet a tyous les mettre en auto au debut?
J m'explique.
J'ai lancé un apt-get update && apt-getupgrade, et donc il m'a dit la liste de
s paqets a mettre a jour.
Je n'ai pas lancé la maj.
Puis j'ai lancé, un aptitude update && a^titude upgrade, et là, il m'a
affiché, les mm paquets qu'avec apt, à mettre à jour, j'ai pas accepté non
plus, pour ne pas enregistrer d'actions dans aptitude, tant que je suis pas
sur qu'il soit bien configuré.
Donc vu qu'aptitude savait deja les bons paquets à mettre à jour, je
comprends pas pkoi il faut mettre tous les paquets en auto au depart lol ?
Pour qu'il soit en mesure de virer des le depart les paquets inutiles? (cad
non utilisés par des paquets marqués "m")
C'est ça, le faire pour tous au début permet de faire un grand ménage. Par la
suite, c'est automatique.
Je viens encore de le vérifier sur la compilation d'un paquet de sid :
apt-get build-dep m'a installé plein de paquets qui ont été automatiquement
enlevés par aptitude dist-upgrade.
Salut,
J'ai essayé, mais finalement, je me sens pas le courage de tout recocher.
Je pense que je prefere l'utiliser en supposant que mnt tout st nikel
,et qu'il y a rien à virer lol.
Le pb, c'est qu'après avoir tout mis en auto, j'avais lancé un pgrade
pour voir, d'ou la grande liste de suppression, j'ai refusé.
J'ai relanc& aptitude, j'ai tout remis en manuel, et malgrès cela, il
veut tjs tout me supprimer...:-(
Une idee, pour le remettre dans son etat initial?
Pq si je remets tout en manuel comme avant, y'a pas de raison, qu'il
veuille tout me virer non?
Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :J'ai profité d'un récent fil pour me mettre à aptitude qui est plus
puissant de ce côté là. Il distingue les paquets installés explicitement
de ceux installés implicitement.
Pour ça, il faut d'abord initialiser la base de données en se tapant tous
les paquets un à un. On commence par tout marquer "automatique" (M) (on
peut le faire sur une branche entière), puis on marque en "manuel" (m) les
paquets de plus haut niveau que l'on souhaite garder.
[...]T'es sur qu'il y a un interet a tyous les mettre en auto au debut?
J m'explique.
J'ai lancé un apt-get update && apt-getupgrade, et donc il m'a dit la liste de
s paqets a mettre a jour.
Je n'ai pas lancé la maj.
Puis j'ai lancé, un aptitude update && a^titude upgrade, et là, il m'a
affiché, les mm paquets qu'avec apt, à mettre à jour, j'ai pas accepté non
plus, pour ne pas enregistrer d'actions dans aptitude, tant que je suis pas
sur qu'il soit bien configuré.
Donc vu qu'aptitude savait deja les bons paquets à mettre à jour, je
comprends pas pkoi il faut mettre tous les paquets en auto au depart lol ?
Pour qu'il soit en mesure de virer des le depart les paquets inutiles? (cad
non utilisés par des paquets marqués "m")
C'est ça, le faire pour tous au début permet de faire un grand ménage. Par la
suite, c'est automatique.
Je viens encore de le vérifier sur la compilation d'un paquet de sid :
apt-get build-dep m'a installé plein de paquets qui ont été automatiquement
enlevés par aptitude dist-upgrade.
Salut,
J'ai essayé, mais finalement, je me sens pas le courage de tout recocher.
Je pense que je prefere l'utiliser en supposant que mnt tout st nikel
,et qu'il y a rien à virer lol.
Le pb, c'est qu'après avoir tout mis en auto, j'avais lancé un pgrade
pour voir, d'ou la grande liste de suppression, j'ai refusé.
J'ai relanc& aptitude, j'ai tout remis en manuel, et malgrès cela, il
veut tjs tout me supprimer...:-(
Une idee, pour le remettre dans son etat initial?
Pq si je remets tout en manuel comme avant, y'a pas de raison, qu'il
veuille tout me virer non?
C'est ce cas là qui m'intéresse. Le logiciel marche aussi bien avec la version n
que la version n+1 de la librairie. Le paquet binaire est construit avec la
version n+1, pourra-t-on l'installer et l'utiliser dans un environnement où il
n'y a que la version n ?
Hmmm, pas vraiment. Je reformule ma question.
Je suis en testing, je télécharge les sources d'un paquet sid, je le compile
avec les librairies de testing, je l'installe et ça marche.
Laquelle de ces assertions est vraie ?
1. si j'avais essayé d'installer le paquet binaire compilé en sid, dpkg
n'aurait rien dit et ça aurait marché.
2. si j'avais forcé l'installation (je ne sais pas si c'est possible, mais
admettons) du paquet binaire compilé en sid, ça aurait marché.
3. si je réussis, d'une manière ou d'une autre, à installer le paquet binaire
compilé en sid, il y a peu de chance que ça marche.
À bien y réfléchir, je commence à me douter que la bonne réponse est 1, et du
même coup à comprendre l'intérêt du fichier /etc/apt/preferences.
C'est ce cas là qui m'intéresse. Le logiciel marche aussi bien avec la version n
que la version n+1 de la librairie. Le paquet binaire est construit avec la
version n+1, pourra-t-on l'installer et l'utiliser dans un environnement où il
n'y a que la version n ?
Hmmm, pas vraiment. Je reformule ma question.
Je suis en testing, je télécharge les sources d'un paquet sid, je le compile
avec les librairies de testing, je l'installe et ça marche.
Laquelle de ces assertions est vraie ?
1. si j'avais essayé d'installer le paquet binaire compilé en sid, dpkg
n'aurait rien dit et ça aurait marché.
2. si j'avais forcé l'installation (je ne sais pas si c'est possible, mais
admettons) du paquet binaire compilé en sid, ça aurait marché.
3. si je réussis, d'une manière ou d'une autre, à installer le paquet binaire
compilé en sid, il y a peu de chance que ça marche.
À bien y réfléchir, je commence à me douter que la bonne réponse est 1, et du
même coup à comprendre l'intérêt du fichier /etc/apt/preferences.
C'est ce cas là qui m'intéresse. Le logiciel marche aussi bien avec la version n
que la version n+1 de la librairie. Le paquet binaire est construit avec la
version n+1, pourra-t-on l'installer et l'utiliser dans un environnement où il
n'y a que la version n ?
Hmmm, pas vraiment. Je reformule ma question.
Je suis en testing, je télécharge les sources d'un paquet sid, je le compile
avec les librairies de testing, je l'installe et ça marche.
Laquelle de ces assertions est vraie ?
1. si j'avais essayé d'installer le paquet binaire compilé en sid, dpkg
n'aurait rien dit et ça aurait marché.
2. si j'avais forcé l'installation (je ne sais pas si c'est possible, mais
admettons) du paquet binaire compilé en sid, ça aurait marché.
3. si je réussis, d'une manière ou d'une autre, à installer le paquet binaire
compilé en sid, il y a peu de chance que ça marche.
À bien y réfléchir, je commence à me douter que la bonne réponse est 1, et du
même coup à comprendre l'intérêt du fichier /etc/apt/preferences.
Leopold BAILLY a écrit :C'est ce cas là qui m'intéresse. Le logiciel marche aussi bien avec la version n
que la version n+1 de la librairie. Le paquet binaire est construit avec la
version n+1, pourra-t-on l'installer et l'utiliser dans un environnement où il
n'y a que la version n ?
du fait même des dépendances, non.
Cas particulier : un paquet dont il n'y a pas vraiment d'intérêt, mis en
dépendance pour raison de cohérence par ex. ou pour fournir une
fonctionnalité additionnelle non vitale et indispensable.
Dans ce dernier cas, equivs permet de "shunter" la gestion des
dépendances (je l'ai fait avec un paquet qui dépend de kcontrol, là pour
eviter d'installer le dit paquet + x dépendances supp.)
Hmmm, pas vraiment. Je reformule ma question.
Je suis en testing, je télécharge les sources d'un paquet sid, je le compile
avec les librairies de testing, je l'installe et ça marche.
Laquelle de ces assertions est vraie ?
1. si j'avais essayé d'installer le paquet binaire compilé en sid, dpkg
n'aurait rien dit et ça aurait marché.
2. si j'avais forcé l'installation (je ne sais pas si c'est possible, mais
admettons) du paquet binaire compilé en sid, ça aurait marché.
3. si je réussis, d'une manière ou d'une autre, à installer le paquet binaire
compilé en sid, il y a peu de chance que ça marche.
À bien y réfléchir, je commence à me douter que la bonne réponse est 1, et du
même coup à comprendre l'intérêt du fichier /etc/apt/preferences.
en fait aucune n'est vrai dans le cas général car la recompilation
implique l'utilisation des 'libs' de la version dans laquelle le paquet
à été compilé.
Leopold BAILLY a écrit :
C'est ce cas là qui m'intéresse. Le logiciel marche aussi bien avec la version n
que la version n+1 de la librairie. Le paquet binaire est construit avec la
version n+1, pourra-t-on l'installer et l'utiliser dans un environnement où il
n'y a que la version n ?
du fait même des dépendances, non.
Cas particulier : un paquet dont il n'y a pas vraiment d'intérêt, mis en
dépendance pour raison de cohérence par ex. ou pour fournir une
fonctionnalité additionnelle non vitale et indispensable.
Dans ce dernier cas, equivs permet de "shunter" la gestion des
dépendances (je l'ai fait avec un paquet qui dépend de kcontrol, là pour
eviter d'installer le dit paquet + x dépendances supp.)
Hmmm, pas vraiment. Je reformule ma question.
Je suis en testing, je télécharge les sources d'un paquet sid, je le compile
avec les librairies de testing, je l'installe et ça marche.
Laquelle de ces assertions est vraie ?
1. si j'avais essayé d'installer le paquet binaire compilé en sid, dpkg
n'aurait rien dit et ça aurait marché.
2. si j'avais forcé l'installation (je ne sais pas si c'est possible, mais
admettons) du paquet binaire compilé en sid, ça aurait marché.
3. si je réussis, d'une manière ou d'une autre, à installer le paquet binaire
compilé en sid, il y a peu de chance que ça marche.
À bien y réfléchir, je commence à me douter que la bonne réponse est 1, et du
même coup à comprendre l'intérêt du fichier /etc/apt/preferences.
en fait aucune n'est vrai dans le cas général car la recompilation
implique l'utilisation des 'libs' de la version dans laquelle le paquet
à été compilé.
Leopold BAILLY a écrit :C'est ce cas là qui m'intéresse. Le logiciel marche aussi bien avec la version n
que la version n+1 de la librairie. Le paquet binaire est construit avec la
version n+1, pourra-t-on l'installer et l'utiliser dans un environnement où il
n'y a que la version n ?
du fait même des dépendances, non.
Cas particulier : un paquet dont il n'y a pas vraiment d'intérêt, mis en
dépendance pour raison de cohérence par ex. ou pour fournir une
fonctionnalité additionnelle non vitale et indispensable.
Dans ce dernier cas, equivs permet de "shunter" la gestion des
dépendances (je l'ai fait avec un paquet qui dépend de kcontrol, là pour
eviter d'installer le dit paquet + x dépendances supp.)
Hmmm, pas vraiment. Je reformule ma question.
Je suis en testing, je télécharge les sources d'un paquet sid, je le compile
avec les librairies de testing, je l'installe et ça marche.
Laquelle de ces assertions est vraie ?
1. si j'avais essayé d'installer le paquet binaire compilé en sid, dpkg
n'aurait rien dit et ça aurait marché.
2. si j'avais forcé l'installation (je ne sais pas si c'est possible, mais
admettons) du paquet binaire compilé en sid, ça aurait marché.
3. si je réussis, d'une manière ou d'une autre, à installer le paquet binaire
compilé en sid, il y a peu de chance que ça marche.
À bien y réfléchir, je commence à me douter que la bonne réponse est 1, et du
même coup à comprendre l'intérêt du fichier /etc/apt/preferences.
en fait aucune n'est vrai dans le cas général car la recompilation
implique l'utilisation des 'libs' de la version dans laquelle le paquet
à été compilé.
Ok, merci.
Mais alors comment expliquer que sur un "upgrade" on voit passer des mises à
jour de librairies sans que les paquets qui en dépendent soient eux-mêmes mis à
jour ?
Par exemple, à l'instant :
,----
| ~$ aptitude dist-upgrade
| ...
| Les paquets suivants seront mis à jour :
| libpq4 lincity
| ...
| Préparation du remplacement de libpq4 8.0.3-15 (en utilisant .../libpq4_8.1.0-2_i386.deb) ...
| ...
`----
libpq4 viens de passer de la version 8.0.3 à 8.1.0, alors que gnugk qui en
dépend n'a pas fait l'objet d'une mise à jour.
Ok, merci.
Mais alors comment expliquer que sur un "upgrade" on voit passer des mises à
jour de librairies sans que les paquets qui en dépendent soient eux-mêmes mis à
jour ?
Par exemple, à l'instant :
,----
| ~$ aptitude dist-upgrade
| ...
| Les paquets suivants seront mis à jour :
| libpq4 lincity
| ...
| Préparation du remplacement de libpq4 8.0.3-15 (en utilisant .../libpq4_8.1.0-2_i386.deb) ...
| ...
`----
libpq4 viens de passer de la version 8.0.3 à 8.1.0, alors que gnugk qui en
dépend n'a pas fait l'objet d'une mise à jour.
Ok, merci.
Mais alors comment expliquer que sur un "upgrade" on voit passer des mises à
jour de librairies sans que les paquets qui en dépendent soient eux-mêmes mis à
jour ?
Par exemple, à l'instant :
,----
| ~$ aptitude dist-upgrade
| ...
| Les paquets suivants seront mis à jour :
| libpq4 lincity
| ...
| Préparation du remplacement de libpq4 8.0.3-15 (en utilisant .../libpq4_8.1.0-2_i386.deb) ...
| ...
`----
libpq4 viens de passer de la version 8.0.3 à 8.1.0, alors que gnugk qui en
dépend n'a pas fait l'objet d'une mise à jour.
Thierry B writes:Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :J'ai profité d'un récent fil pour me mettre à aptitude qui est plus
puissant de ce côté là. Il distingue les paquets installés explicitement
de ceux installés implicitement.
Pour ça, il faut d'abord initialiser la base de données en se tapant tous
les paquets un à un. On commence par tout marquer "automatique" (M) (on
peut le faire sur une branche entière), puis on marque en "manuel" (m) les
paquets de plus haut niveau que l'on souhaite garder.
[...]T'es sur qu'il y a un interet a tyous les mettre en auto au debut?
J m'explique.
J'ai lancé un apt-get update && apt-getupgrade, et donc il m'a dit la liste de
s paqets a mettre a jour.
Je n'ai pas lancé la maj.
Puis j'ai lancé, un aptitude update && a^titude upgrade, et là, il m'a
affiché, les mm paquets qu'avec apt, à mettre à jour, j'ai pas accepté non
plus, pour ne pas enregistrer d'actions dans aptitude, tant que je suis pas
sur qu'il soit bien configuré.
Donc vu qu'aptitude savait deja les bons paquets à mettre à jour, je
comprends pas pkoi il faut mettre tous les paquets en auto au depart lol ?
Pour qu'il soit en mesure de virer des le depart les paquets inutiles? (cad
non utilisés par des paquets marqués "m")
C'est ça, le faire pour tous au début permet de faire un grand ménage. Par la
suite, c'est automatique.
Je viens encore de le vérifier sur la compilation d'un paquet de sid :
apt-get build-dep m'a installé plein de paquets qui ont été automatiquement
enlevés par aptitude dist-upgrade.
Salut,
J'ai essayé, mais finalement, je me sens pas le courage de tout recocher.
Je pense que je prefere l'utiliser en supposant que mnt tout st nikel
,et qu'il y a rien à virer lol.
Le pb, c'est qu'après avoir tout mis en auto, j'avais lancé un pgrade
pour voir, d'ou la grande liste de suppression, j'ai refusé.
J'ai relanc& aptitude, j'ai tout remis en manuel, et malgrès cela, il
veut tjs tout me supprimer...:-(
Une idee, pour le remettre dans son etat initial?
Pq si je remets tout en manuel comme avant, y'a pas de raison, qu'il
veuille tout me virer non?
Ça ne paraît pas très logique, mais il doit y avoir une raison.
Quoi qu'il en soit, "+" devrait remplacer avantageusement "m" ; si tu le fais
sur la branche "paquets installés", tout devrait rentrer dans l'ordre.
Thierry B <debian@thierry.eu.org> writes:
Leopold BAILLY a écrit :
Thierry B <debian@thierry.eu.org> writes:
Leopold BAILLY a écrit :
Thierry B <debian@thierry.eu.org> writes:
Leopold BAILLY a écrit :
J'ai profité d'un récent fil pour me mettre à aptitude qui est plus
puissant de ce côté là. Il distingue les paquets installés explicitement
de ceux installés implicitement.
Pour ça, il faut d'abord initialiser la base de données en se tapant tous
les paquets un à un. On commence par tout marquer "automatique" (M) (on
peut le faire sur une branche entière), puis on marque en "manuel" (m) les
paquets de plus haut niveau que l'on souhaite garder.
[...]
T'es sur qu'il y a un interet a tyous les mettre en auto au debut?
J m'explique.
J'ai lancé un apt-get update && apt-getupgrade, et donc il m'a dit la liste de
s paqets a mettre a jour.
Je n'ai pas lancé la maj.
Puis j'ai lancé, un aptitude update && a^titude upgrade, et là, il m'a
affiché, les mm paquets qu'avec apt, à mettre à jour, j'ai pas accepté non
plus, pour ne pas enregistrer d'actions dans aptitude, tant que je suis pas
sur qu'il soit bien configuré.
Donc vu qu'aptitude savait deja les bons paquets à mettre à jour, je
comprends pas pkoi il faut mettre tous les paquets en auto au depart lol ?
Pour qu'il soit en mesure de virer des le depart les paquets inutiles? (cad
non utilisés par des paquets marqués "m")
C'est ça, le faire pour tous au début permet de faire un grand ménage. Par la
suite, c'est automatique.
Je viens encore de le vérifier sur la compilation d'un paquet de sid :
apt-get build-dep m'a installé plein de paquets qui ont été automatiquement
enlevés par aptitude dist-upgrade.
Salut,
J'ai essayé, mais finalement, je me sens pas le courage de tout recocher.
Je pense que je prefere l'utiliser en supposant que mnt tout st nikel
,et qu'il y a rien à virer lol.
Le pb, c'est qu'après avoir tout mis en auto, j'avais lancé un pgrade
pour voir, d'ou la grande liste de suppression, j'ai refusé.
J'ai relanc& aptitude, j'ai tout remis en manuel, et malgrès cela, il
veut tjs tout me supprimer...:-(
Une idee, pour le remettre dans son etat initial?
Pq si je remets tout en manuel comme avant, y'a pas de raison, qu'il
veuille tout me virer non?
Ça ne paraît pas très logique, mais il doit y avoir une raison.
Quoi qu'il en soit, "+" devrait remplacer avantageusement "m" ; si tu le fais
sur la branche "paquets installés", tout devrait rentrer dans l'ordre.
Thierry B writes:Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :Thierry B writes:Leopold BAILLY a écrit :J'ai profité d'un récent fil pour me mettre à aptitude qui est plus
puissant de ce côté là. Il distingue les paquets installés explicitement
de ceux installés implicitement.
Pour ça, il faut d'abord initialiser la base de données en se tapant tous
les paquets un à un. On commence par tout marquer "automatique" (M) (on
peut le faire sur une branche entière), puis on marque en "manuel" (m) les
paquets de plus haut niveau que l'on souhaite garder.
[...]T'es sur qu'il y a un interet a tyous les mettre en auto au debut?
J m'explique.
J'ai lancé un apt-get update && apt-getupgrade, et donc il m'a dit la liste de
s paqets a mettre a jour.
Je n'ai pas lancé la maj.
Puis j'ai lancé, un aptitude update && a^titude upgrade, et là, il m'a
affiché, les mm paquets qu'avec apt, à mettre à jour, j'ai pas accepté non
plus, pour ne pas enregistrer d'actions dans aptitude, tant que je suis pas
sur qu'il soit bien configuré.
Donc vu qu'aptitude savait deja les bons paquets à mettre à jour, je
comprends pas pkoi il faut mettre tous les paquets en auto au depart lol ?
Pour qu'il soit en mesure de virer des le depart les paquets inutiles? (cad
non utilisés par des paquets marqués "m")
C'est ça, le faire pour tous au début permet de faire un grand ménage. Par la
suite, c'est automatique.
Je viens encore de le vérifier sur la compilation d'un paquet de sid :
apt-get build-dep m'a installé plein de paquets qui ont été automatiquement
enlevés par aptitude dist-upgrade.
Salut,
J'ai essayé, mais finalement, je me sens pas le courage de tout recocher.
Je pense que je prefere l'utiliser en supposant que mnt tout st nikel
,et qu'il y a rien à virer lol.
Le pb, c'est qu'après avoir tout mis en auto, j'avais lancé un pgrade
pour voir, d'ou la grande liste de suppression, j'ai refusé.
J'ai relanc& aptitude, j'ai tout remis en manuel, et malgrès cela, il
veut tjs tout me supprimer...:-(
Une idee, pour le remettre dans son etat initial?
Pq si je remets tout en manuel comme avant, y'a pas de raison, qu'il
veuille tout me virer non?
Ça ne paraît pas très logique, mais il doit y avoir une raison.
Quoi qu'il en soit, "+" devrait remplacer avantageusement "m" ; si tu le fais
sur la branche "paquets installés", tout devrait rentrer dans l'ordre.
