J'ai install=C3=A9 il y a quelques semaines deux machines sous Stretch ave=
c
l'installeur en vigueur =C3=A0 l'=C3=A9poque. R=C3=A9guli=C3=A8rement, j'op=
=C3=A8re sur ces machines
une s=C3=A9quence "apt-get update; apt-get -y upgrade".
Sur chaque machine, j'observe que le noyau est en version 4.8.
J'ai install=C3=A9 ce matin 2 VM (1 en i386, 1 en amd64) =C3=A0 partir de l=
a version
rc2 de l'installeur .
Sur chacune, le noyau est en 4.9.
1. J'imaginai que sur Stretch, une s=C3=A9quence "apt-get update; apt-get -=
y
upgrade" change automatiquement la version du noyau, s'il y a lieu.
En d'autres termes, j'imaginai qu'une machine install=C3=A9e en Janvier, mi=
se =C3=A0
jour avec "apt-get update; apt-get -y upgrade" aurait exactement les m=C3=
=AAmes
versions de logiciel qu'une nouvelle machine install=C3=A9e le jour m=C3=AA=
me.
Est-il exact d'imaginer cela ?
2. Si non, existe-t-il une commande "idempotente" (ie qui ne fait rien si
la version du noyau n'a pas chang=C3=A9 mais qui fait la mise =C3=A0 jour q=
uand le
noyau a chang=C3=A9) qui apporte ce changement de version ?
Slts
Le 14 mars 2017 =C3=A0 15:36, Jean-Marc <jean-marc@6jf.be> a =C3=A9crit :
> Tue, 14 Mar 2017 14:29:57 +0100
> Olivier <oza.4h07@gmail.com> =C3=A9crivait :
>
> > # uname -r
> > 4.8.0-2-686-pae
> >
> > # apt-get install linux-headers-`uname -r`
> > Lecture des listes de paquets... Fait
> > Construction de l'arbre des d=C3=A9pendances
> > Lecture des informations d'=C3=A9tat... Fait
> > E: Impossible de trouver le paquet linux-headers-4.8.0-2-686-pae
> > E: Couldn't find any package by glob 'linux-headers-4.8.0-2-686-pae'
> > E: Impossible de trouver de paquet correspondant =C3=A0 l'expression
> rationnelle
> > =C2=AB linux-headers-4.8.0-2-686-pae =C2=BB
>
> Je viens de faire une recherche sur le site de Debian et il n'existe plus
> que 2 ou 3 paquets pour la version 4.8 et uniquement dans les backports d=
e
> Jessie.
>
> Donc, je pense que c'est normal que apt-get ne puisse pas installer un
> paquet qui n'existe plus.
>
>
> Bien =C3=A0 toi,
>
>
> Jean-Marc <jean-marc@6jf.be>
>
<div dir=3D"ltr"><div><div><div><div><div><div>Bonjour,<br><br></div><div>J=
'ai install=C3=A9 il y a quelques semaines deux machines=C2=A0 sous Str=
etch avec l'installeur en vigueur =C3=A0 l'=C3=A9poque. R=C3=A9guli=
=C3=A8rement, j'op=C3=A8re sur ces machines une s=C3=A9quence "apt=
-get update; apt-get -y upgrade".</div><div><br>Sur chaque machine, j&=
#39;observe que le noyau est en version 4.8.<br></div><br></div>J'ai in=
stall=C3=A9 ce matin 2 VM (1 en i386, 1 en amd64) =C3=A0 partir de la versi=
on rc2 de l'installeur .<br></div>Sur chacune, le noyau est en 4.9.<br>=
<br><br></div>1. J'imaginai que sur Stretch, une s=C3=A9quence "ap=
t-get update; apt-get -y upgrade" change automatiquement la version du=
noyau, s'il y a lieu.<br></div><div>En d'autres termes, j'imag=
inai qu'une machine install=C3=A9e en Janvier, mise =C3=A0 jour avec &=
quot;apt-get update; apt-get -y upgrade" aurait exactement les m=C3=AA=
mes versions de logiciel qu'une nouvelle machine install=C3=A9e le jour=
m=C3=AAme.<br></div>Est-il exact d'imaginer cela ?<br></div><br><div><=
div>2. Si non, existe-t-il une commande "idempotente" (ie qui ne =
fait rien si la version du noyau n'a pas chang=C3=A9 mais qui fait la m=
ise =C3=A0 jour quand le noyau a chang=C3=A9) qui apporte ce changement de =
version ?<br><br></div><div>Slts<br></div><div><div><div><div><div><div><di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">Le 14 mars 2017=
=C3=A0 15:36, Jean-Marc <span dir=3D"ltr"><<a target=3D"_blank" href=3D=
"mailto:jean-marc@6jf.be">jean-marc@6jf.be</a>></span> a =C3=A9crit :<br=
><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex" class=3D"gmail_quote">Tue, 14 Mar 2017 14:29:5=
7 +0100<br>
Olivier <<a target=3D"_blank" href=3D"mailto:oza.4h07@gmail.com">oza.4h0=
7@gmail.com</a>> =C3=A9crivait :<br>
<span><br>
> # uname -r<br>
> 4.8.0-2-686-pae<br>
><br>
> # apt-get install linux-headers-`uname -r`<br>
> Lecture des listes de paquets... Fait<br>
> Construction de l'arbre des d=C3=A9pendances<br>
> Lecture des informations d'=C3=A9tat... Fait<br>
> E: Impossible de trouver le paquet linux-headers-4.8.0-2-686-pae<br>
> E: Couldn't find any package by glob 'linux-headers-4.8.0-2-68=
6-pae<wbr>'<br>
> E: Impossible de trouver de paquet correspondant =C3=A0 l'expressi=
on rationnelle<br>
> =C2=AB linux-headers-4.8.0-2-686-pae =C2=BB<br>
<br>
</span>Je viens de faire une recherche sur le site de Debian et il n'ex=
iste plus que 2 ou 3 paquets pour la version 4.8 et uniquement dans les bac=
kports de Jessie.<br>
<br>
Donc, je pense que c'est normal que apt-get ne puisse pas installer un =
paquet qui n'existe plus.<br>
<br>
<br>
Bien =C3=A0 toi,<br>
<br>
<br>
Jean-Marc <<a target=3D"_blank" href=3D"mailto:jean-marc@6jf.be">jean-ma=
rc@6jf.be</a>><br>
</blockquote></div><br></div></div></div></div></div></div></div></div></di=
v></div>
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
daniel huhardeaux
Le 16/03/2017 à 09:30, Olivier a écrit :
Bonjour, J'ai installé il y a quelques semaines deux machines sous Stretch avec l'installeur en vigueur à l'époque. Régulièrement, j'opère sur ces machines une séquence "apt-get update; apt-get -y upgrade". Sur chaque machine, j'observe que le noyau est en version 4.8. J'ai installé ce matin 2 VM (1 en i386, 1 en amd64) à partir de la version rc2 de l'installeur . Sur chacune, le noyau est en 4.9. 1. J'imaginai que sur Stretch, une séquence "apt-get update; apt-get -y upgrade" change automatiquement la version du noyau, s'il y a lieu. En d'autres termes, j'imaginai qu'une machine installée en Janvier, mise à jour avec "apt-get update; apt-get -y upgrade" aurait exactement les mêmes versions de logiciel qu'une nouvelle machine installée le jour même. Est-il exact d'imaginer cela ? 2. Si non, existe-t-il une commande "idempotente" (ie qui ne fait rien si la version du noyau n'a pas changé mais qui fait la mise à jour quand le noyau a changé) qui apporte ce changement de version ?
C'est le paquet linux-image-[amd64|i386] qui gère. Soit il n'est pas installé sur les 2 "anciennes" machines, soit il pointe sur le noyau 4.8
Slts Le 14 mars 2017 à 15:36, Jean-Marc <mailto: a écrit : Tue, 14 Mar 2017 14:29:57 +0100 Olivier <mailto: écrivait :
# uname -r 4.8.0-2-686-pae # apt-get install linux-headers-`uname -r` Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait E: Impossible de trouver le paquet linux-headers-4.8.0-2-686-pae E: Couldn't find any package by glob 'linux-headers-4.8.0-2-686-pae' E: Impossible de trouver de paquet correspondant à l'expression
rationnelle
« linux-headers-4.8.0-2-686-pae »
Je viens de faire une recherche sur le site de Debian et il n'existe plus que 2 ou 3 paquets pour la version 4.8 et uniquement dans les backports de Jessie. Donc, je pense que c'est normal que apt-get ne puisse pas installer un paquet qui n'existe plus. Bien à toi, Jean-Marc <mailto:
Le 16/03/2017 à 09:30, Olivier a écrit :
Bonjour,
J'ai installé il y a quelques semaines deux machines sous Stretch
avec l'installeur en vigueur à l'époque. Régulièrement, j'opère sur
ces machines une séquence "apt-get update; apt-get -y upgrade".
Sur chaque machine, j'observe que le noyau est en version 4.8.
J'ai installé ce matin 2 VM (1 en i386, 1 en amd64) à partir de la
version rc2 de l'installeur .
Sur chacune, le noyau est en 4.9.
1. J'imaginai que sur Stretch, une séquence "apt-get update; apt-get
-y upgrade" change automatiquement la version du noyau, s'il y a lieu.
En d'autres termes, j'imaginai qu'une machine installée en Janvier,
mise à jour avec "apt-get update; apt-get -y upgrade" aurait
exactement les mêmes versions de logiciel qu'une nouvelle machine
installée le jour même.
Est-il exact d'imaginer cela ?
2. Si non, existe-t-il une commande "idempotente" (ie qui ne fait rien
si la version du noyau n'a pas changé mais qui fait la mise à jour
quand le noyau a changé) qui apporte ce changement de version ?
C'est le paquet linux-image-[amd64|i386] qui gère. Soit il n'est pas
installé sur les 2 "anciennes" machines, soit il pointe sur le noyau 4.8
Slts
Le 14 mars 2017 à 15:36, Jean-Marc <jean-marc@6jf.be
<mailto:jean-marc@6jf.be>> a écrit :
> # uname -r
> 4.8.0-2-686-pae
>
> # apt-get install linux-headers-`uname -r`
> Lecture des listes de paquets... Fait
> Construction de l'arbre des dépendances
> Lecture des informations d'état... Fait
> E: Impossible de trouver le paquet linux-headers-4.8.0-2-686-pae
> E: Couldn't find any package by glob 'linux-headers-4.8.0-2-686-pae'
> E: Impossible de trouver de paquet correspondant à l'expression
rationnelle
> « linux-headers-4.8.0-2-686-pae »
Je viens de faire une recherche sur le site de Debian et il
n'existe plus que 2 ou 3 paquets pour la version 4.8 et uniquement
dans les backports de Jessie.
Donc, je pense que c'est normal que apt-get ne puisse pas
installer un paquet qui n'existe plus.
Bonjour, J'ai installé il y a quelques semaines deux machines sous Stretch avec l'installeur en vigueur à l'époque. Régulièrement, j'opère sur ces machines une séquence "apt-get update; apt-get -y upgrade". Sur chaque machine, j'observe que le noyau est en version 4.8. J'ai installé ce matin 2 VM (1 en i386, 1 en amd64) à partir de la version rc2 de l'installeur . Sur chacune, le noyau est en 4.9. 1. J'imaginai que sur Stretch, une séquence "apt-get update; apt-get -y upgrade" change automatiquement la version du noyau, s'il y a lieu. En d'autres termes, j'imaginai qu'une machine installée en Janvier, mise à jour avec "apt-get update; apt-get -y upgrade" aurait exactement les mêmes versions de logiciel qu'une nouvelle machine installée le jour même. Est-il exact d'imaginer cela ? 2. Si non, existe-t-il une commande "idempotente" (ie qui ne fait rien si la version du noyau n'a pas changé mais qui fait la mise à jour quand le noyau a changé) qui apporte ce changement de version ?
C'est le paquet linux-image-[amd64|i386] qui gère. Soit il n'est pas installé sur les 2 "anciennes" machines, soit il pointe sur le noyau 4.8
Slts Le 14 mars 2017 à 15:36, Jean-Marc <mailto: a écrit : Tue, 14 Mar 2017 14:29:57 +0100 Olivier <mailto: écrivait :
# uname -r 4.8.0-2-686-pae # apt-get install linux-headers-`uname -r` Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait E: Impossible de trouver le paquet linux-headers-4.8.0-2-686-pae E: Couldn't find any package by glob 'linux-headers-4.8.0-2-686-pae' E: Impossible de trouver de paquet correspondant à l'expression
rationnelle
« linux-headers-4.8.0-2-686-pae »
Je viens de faire une recherche sur le site de Debian et il n'existe plus que 2 ou 3 paquets pour la version 4.8 et uniquement dans les backports de Jessie. Donc, je pense que c'est normal que apt-get ne puisse pas installer un paquet qui n'existe plus. Bien à toi, Jean-Marc <mailto:
Ce que j'ai du mal à comprendre, c'est pourquoi le passage de 4.8 en 4.9 ne s'opère pas automatiquement : je n'ai jamais spécifié la version 4.8, j'ai à l'époque spécifié la version courante qui était la 4.8. Si la version courante change, je m'attends à ce que mon noyau suive, ni plus ni moins, ne serait-ce que justement, pour garder la possibilité des en-têtes si j'en ai envie..
Que donne « dpkg -l | grep linux-image » sur ta machine ? Normalement, c'est le principe du métapackage linux-image-amd64 de faire ce que tu dis. -- François Lafont
On 03/16/2017 05:21 PM, Olivier wrote:
Ce que j'ai du mal à comprendre, c'est pourquoi le passage de 4.8 en 4.9 ne
s'opère pas automatiquement : je n'ai jamais spécifié la version 4.8, j'ai
à l'époque spécifié la version courante qui était la 4.8.
Si la version courante change, je m'attends à ce que mon noyau suive, ni
plus ni moins, ne serait-ce que justement, pour garder la possibilité des
en-têtes si j'en ai envie..
Que donne « dpkg -l | grep linux-image » sur ta machine ?
Normalement, c'est le principe du métapackage linux-image-amd64 de faire
ce que tu dis.
Ce que j'ai du mal à comprendre, c'est pourquoi le passage de 4.8 en 4.9 ne s'opère pas automatiquement : je n'ai jamais spécifié la version 4.8, j'ai à l'époque spécifié la version courante qui était la 4.8. Si la version courante change, je m'attends à ce que mon noyau suive, ni plus ni moins, ne serait-ce que justement, pour garder la possibilité des en-têtes si j'en ai envie..
Que donne « dpkg -l | grep linux-image » sur ta machine ? Normalement, c'est le principe du métapackage linux-image-amd64 de faire ce que tu dis. -- François Lafont
maderios
On 03/16/2017 07:13 PM, Francois Lafont wrote:
On 03/16/2017 05:21 PM, Olivier wrote:
Ce que j'ai du mal à comprendre, c'est pourquoi le passage de 4.8 en 4.9 ne s'opère pas automatiquement : je n'ai jamais spécifié la version 4.8, j'ai à l'époque spécifié la version courante qui était la 4.8. Si la version courante change, je m'attends à ce que mon noyau suive, ni plus ni moins, ne serait-ce que justement, pour garder la possibilité des en-têtes si j'en ai envie..
Que donne « dpkg -l | grep linux-image » sur ta machine ? Normalement, c'est le principe du métapackage linux-image-amd64 de faire ce que tu dis.
Bonjour Il faut quand même admettre que chez Debian, la manière de nommer les noyaux n'est pas claire et même trompeuse. Sur Stretch dpkg -l | grep linux-image ii linux-image-4.9.0-2-amd64 4.9.13-1 amd64 Linux 4.9 for 64-bit PCs (signed) ii linux-image-amd64 4.9+79 amd64 Linux for 64-bit PCs (meta-package) Que vient faire ce '4.9+79' concernant le '4.9.13'? Mystère... Avec d'autres distributions, tout ce qui concerne le même noyau porte le même numéro. Le pire, ce sont les entrées de Grub où ne sont pas mentionnées les versions de noyaux... On ne sait jamais où on en est mais bon, c'est Debian... :) -- Maderios
On 03/16/2017 07:13 PM, Francois Lafont wrote:
On 03/16/2017 05:21 PM, Olivier wrote:
Ce que j'ai du mal à comprendre, c'est pourquoi le passage de 4.8 en 4.9 ne
s'opère pas automatiquement : je n'ai jamais spécifié la version 4.8, j'ai
à l'époque spécifié la version courante qui était la 4.8.
Si la version courante change, je m'attends à ce que mon noyau suive, ni
plus ni moins, ne serait-ce que justement, pour garder la possibilité des
en-têtes si j'en ai envie..
Que donne « dpkg -l | grep linux-image » sur ta machine ?
Normalement, c'est le principe du métapackage linux-image-amd64 de faire
ce que tu dis.
Bonjour
Il faut quand même admettre que chez Debian, la manière de nommer les
noyaux n'est pas claire et même trompeuse.
Sur Stretch
dpkg -l | grep linux-image
ii linux-image-4.9.0-2-amd64 4.9.13-1
amd64 Linux 4.9 for 64-bit PCs
(signed)
ii linux-image-amd64 4.9+79
amd64 Linux for 64-bit PCs
(meta-package)
Que vient faire ce '4.9+79' concernant le '4.9.13'? Mystère...
Avec d'autres distributions, tout ce qui concerne le même noyau porte le
même numéro. Le pire, ce sont les entrées de Grub où ne sont pas
mentionnées les versions de noyaux... On ne sait jamais où on en est
mais bon, c'est Debian... :)
--
Maderios
Ce que j'ai du mal à comprendre, c'est pourquoi le passage de 4.8 en 4.9 ne s'opère pas automatiquement : je n'ai jamais spécifié la version 4.8, j'ai à l'époque spécifié la version courante qui était la 4.8. Si la version courante change, je m'attends à ce que mon noyau suive, ni plus ni moins, ne serait-ce que justement, pour garder la possibilité des en-têtes si j'en ai envie..
Que donne « dpkg -l | grep linux-image » sur ta machine ? Normalement, c'est le principe du métapackage linux-image-amd64 de faire ce que tu dis.
Bonjour Il faut quand même admettre que chez Debian, la manière de nommer les noyaux n'est pas claire et même trompeuse. Sur Stretch dpkg -l | grep linux-image ii linux-image-4.9.0-2-amd64 4.9.13-1 amd64 Linux 4.9 for 64-bit PCs (signed) ii linux-image-amd64 4.9+79 amd64 Linux for 64-bit PCs (meta-package) Que vient faire ce '4.9+79' concernant le '4.9.13'? Mystère... Avec d'autres distributions, tout ce qui concerne le même noyau porte le même numéro. Le pire, ce sont les entrées de Grub où ne sont pas mentionnées les versions de noyaux... On ne sait jamais où on en est mais bon, c'est Debian... :) -- Maderios
Francois Lafont
Bonsoir, On 03/16/2017 07:55 PM, maderios wrote:
Il faut quand même admettre que chez Debian, la manière de nommer les noyaux n'est pas claire et même trompeuse. Sur Stretch dpkg -l | grep linux-image ii linux-image-4.9.0-2-amd64 4.9.13-1 amd64 Linux 4.9 for 64-bit PCs (signed) ii linux-image-amd64 4.9+79 amd64 Linux for 64-bit PCs (meta-package)
Voilà et moi par exemple sur ma Jessie j'ai ça : ii linux-image-3.16.0-4-amd64 3.16.39-1+deb8u2 amd64 ii linux-image-amd64 3.16+63 amd64 linux-image-amd64 est un métapackage, ie il ne contient pour ainsi dire rien ou presque comme on peut le voir avec « dpkg -L linux-image-amd64 ». Son rôle est d'avoir une dépendance d'un paquet linux-image-W.X.Y-Z-amd64 qui lui contiendra bien un noyau Linux. Quand le paquet linux-image-amd64 est mis à jour, c'est en fait juste sa dépendance qui va changer et tirer avec lui l'installation d'une nouvelle version du noyau Linux. Si on désinstalle le package linux-image-amd64, globalement on ne supprime rien mais on risque de passer à côté d'un changement de numéro de version du noyau. Perso, je verrais bien le PO se trouver dans cette situation où le paquet linux-image-amd64 n'est pas installé.
Que vient faire ce '4.9+79' concernant le '4.9.13'? Mystère... Avec d'autres distributions, tout ce qui concerne le même noyau porte le même numéro. Le pire, ce sont les entrées de Grub où ne sont pas mentionnées les versions de noyaux... On ne sait jamais où on en est mais bon, c'est Debian... :)
Faut reconnaître que la nomenclature des numéros de version, c'est un peu compliqué parfois, même si dans les grandes lignes ça correspond souvent à quelque chose de simple comme (c'est le premier exemple que m'est venu sous ma Jessie) : python3-minimal => 3.4.2-2 qui signifie que le paquet est basé sur la version 3.4.2 du programme upstream (ie Python3 en l'occurrence ici) et "-2" correspond au numéro de révision du paquet. Après, ça peut être plus compliqué que ça et il y a de la doc ici par exemple : https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version Après, pour le « 4.9+79 » du package linux-image-amd64, c'est vrai que c'est pas super clair. On peut imaginer que le 4.9 correspond à la version du noyau qui se cache derrière le métapackage (jusque là je me mouille pas trop). Quant au "+79", j'ai bien l'impression qui'l est incrémenté tout simplement à chaque mise à jour du paquet linux-image-amd64. On peut s'en rendre compte en parcourant son changelog : zcat /usr/share/doc/linux-image-amd64/changelog.gz | less Par exemple lors du passage du noyau 3.13 à 3.14, ce numéro est tout simplement passé de 56 à 57. Mais oui, dans le détail, la nomenclature des numéros de version c'est un peu compliqué. -- François Lafont
Bonsoir,
On 03/16/2017 07:55 PM, maderios wrote:
Il faut quand même admettre que chez Debian, la manière de nommer les
noyaux n'est pas claire et même trompeuse. Sur Stretch dpkg -l | grep
linux-image ii linux-image-4.9.0-2-amd64
4.9.13-1 amd64 Linux 4.9 for
64-bit PCs (signed) ii linux-image-amd64
4.9+79 amd64 Linux for 64-bit
PCs (meta-package)
Voilà et moi par exemple sur ma Jessie j'ai ça :
ii linux-image-3.16.0-4-amd64 3.16.39-1+deb8u2 amd64
ii linux-image-amd64 3.16+63 amd64
linux-image-amd64 est un métapackage, ie il ne contient pour ainsi dire
rien ou presque comme on peut le voir avec « dpkg -L linux-image-amd64 ».
Son rôle est d'avoir une dépendance d'un paquet linux-image-W.X.Y-Z-amd64
qui lui contiendra bien un noyau Linux.
Quand le paquet linux-image-amd64 est mis à jour, c'est en fait juste
sa dépendance qui va changer et tirer avec lui l'installation d'une
nouvelle version du noyau Linux.
Si on désinstalle le package linux-image-amd64, globalement on ne
supprime rien mais on risque de passer à côté d'un changement de
numéro de version du noyau. Perso, je verrais bien le PO se trouver
dans cette situation où le paquet linux-image-amd64 n'est pas
installé.
Que vient faire ce '4.9+79' concernant le '4.9.13'? Mystère... Avec
d'autres distributions, tout ce qui concerne le même noyau porte le
même numéro. Le pire, ce sont les entrées de Grub où ne sont pas
mentionnées les versions de noyaux... On ne sait jamais où on en est
mais bon, c'est Debian... :)
Faut reconnaître que la nomenclature des numéros de version, c'est
un peu compliqué parfois, même si dans les grandes lignes ça correspond
souvent à quelque chose de simple comme (c'est le premier exemple que
m'est venu sous ma Jessie) :
python3-minimal => 3.4.2-2
qui signifie que le paquet est basé sur la version 3.4.2 du programme
upstream (ie Python3 en l'occurrence ici) et "-2" correspond au numéro
de révision du paquet. Après, ça peut être plus compliqué que ça et il
y a de la doc ici par exemple :
Après, pour le « 4.9+79 » du package linux-image-amd64, c'est vrai
que c'est pas super clair. On peut imaginer que le 4.9 correspond
à la version du noyau qui se cache derrière le métapackage (jusque
là je me mouille pas trop). Quant au "+79", j'ai bien l'impression
qui'l est incrémenté tout simplement à chaque mise à jour du paquet
linux-image-amd64. On peut s'en rendre compte en parcourant son
changelog :
zcat /usr/share/doc/linux-image-amd64/changelog.gz | less
Par exemple lors du passage du noyau 3.13 à 3.14, ce numéro est
tout simplement passé de 56 à 57. Mais oui, dans le détail, la
nomenclature des numéros de version c'est un peu compliqué.
Il faut quand même admettre que chez Debian, la manière de nommer les noyaux n'est pas claire et même trompeuse. Sur Stretch dpkg -l | grep linux-image ii linux-image-4.9.0-2-amd64 4.9.13-1 amd64 Linux 4.9 for 64-bit PCs (signed) ii linux-image-amd64 4.9+79 amd64 Linux for 64-bit PCs (meta-package)
Voilà et moi par exemple sur ma Jessie j'ai ça : ii linux-image-3.16.0-4-amd64 3.16.39-1+deb8u2 amd64 ii linux-image-amd64 3.16+63 amd64 linux-image-amd64 est un métapackage, ie il ne contient pour ainsi dire rien ou presque comme on peut le voir avec « dpkg -L linux-image-amd64 ». Son rôle est d'avoir une dépendance d'un paquet linux-image-W.X.Y-Z-amd64 qui lui contiendra bien un noyau Linux. Quand le paquet linux-image-amd64 est mis à jour, c'est en fait juste sa dépendance qui va changer et tirer avec lui l'installation d'une nouvelle version du noyau Linux. Si on désinstalle le package linux-image-amd64, globalement on ne supprime rien mais on risque de passer à côté d'un changement de numéro de version du noyau. Perso, je verrais bien le PO se trouver dans cette situation où le paquet linux-image-amd64 n'est pas installé.
Que vient faire ce '4.9+79' concernant le '4.9.13'? Mystère... Avec d'autres distributions, tout ce qui concerne le même noyau porte le même numéro. Le pire, ce sont les entrées de Grub où ne sont pas mentionnées les versions de noyaux... On ne sait jamais où on en est mais bon, c'est Debian... :)
Faut reconnaître que la nomenclature des numéros de version, c'est un peu compliqué parfois, même si dans les grandes lignes ça correspond souvent à quelque chose de simple comme (c'est le premier exemple que m'est venu sous ma Jessie) : python3-minimal => 3.4.2-2 qui signifie que le paquet est basé sur la version 3.4.2 du programme upstream (ie Python3 en l'occurrence ici) et "-2" correspond au numéro de révision du paquet. Après, ça peut être plus compliqué que ça et il y a de la doc ici par exemple : https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version Après, pour le « 4.9+79 » du package linux-image-amd64, c'est vrai que c'est pas super clair. On peut imaginer que le 4.9 correspond à la version du noyau qui se cache derrière le métapackage (jusque là je me mouille pas trop). Quant au "+79", j'ai bien l'impression qui'l est incrémenté tout simplement à chaque mise à jour du paquet linux-image-amd64. On peut s'en rendre compte en parcourant son changelog : zcat /usr/share/doc/linux-image-amd64/changelog.gz | less Par exemple lors du passage du noyau 3.13 à 3.14, ce numéro est tout simplement passé de 56 à 57. Mais oui, dans le détail, la nomenclature des numéros de version c'est un peu compliqué. -- François Lafont
$ sudo apt-get -s dist-upgrade Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Calcul de la mise à jour... Fait Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires : bijiben libsofia-sip-ua-glib3 libsofia-sip-ua0 telepathy-rakia Veuillez utiliser « sudo apt autoremove » pour les supprimer. Les NOUVEAUX paquets suivants seront installés : firmware-linux-free gnome-calendar irqbalance libopenmpt0 libpgm-5.2-0 libproxy1-plugin-gsettings libproxy1-plugin-networkmanager libsaxonhe-java linux-image-4.9.0-2-686-pae Les paquets suivants seront mis à jour : gnome gnome-core gstreamer1.0-libav libavdevice57 libavfilter6 libavformat57 libgegl-0.3-0 libopencv-calib3d2.4v5 libopencv-core2.4v5 libopencv-features2d2.4v5 libopencv-flann2.4v5 libopencv-highgui2.4-deb0 libopencv-imgproc2.4v5 libopencv-objdetect2.4v5 libopencv-video2.4v5 libxmlbeans-java libzmq5 linux-image-686-pae 18 mis à jour, 9 nouvellement installés, 0 à enlever et 0 non mis à jour. Si j'en crois ce qui précède, linux-image n'est pas mis à jour par dist-upgrade.
Si tu regardes attentivement, tu verras linux-image-686-pae dans la liste d es paquets qui seront mis à jour et linux-image-4.9.0-2-686-pae dans l a liste des nouveaux paquets. Je pensais que c'est ce que tu voulais. Jean-Marc --Signature=_Fri__17_Mar_2017_10_34_27_+0100_frEBnf6J4Nll4wC7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEEWjgcRC0dCXkfm9hQHHLXC3pxPwFAljLraMACgkQQHHLXC3p xPw4Dg/9FRhPnObIkJ+Il1vksgO3QQN1HDVbVA2F+0UHWeaf9wW5vUAUH5GDWb+4 y8Hdbu+J1f7+YuSSPWZbCipQK6U/aJBVUp7L8VV0Ryy+ng2qHK6pp6xn7KZHzDqD /GltckpPtWBA2mT1jy5F5MYuThigfNjzG53LwffGI1v4ooV/O1gOJp5zTpl3oXs7 8pUQEHL6+0qf/WWzae4/FGIXo1o3bppF1JYJwI3PjU+5zGmbxHLQWEzWc8j6u+t9 Pvxj2j8SXLfHYRdi5dKe5Q3M+jy/EC/YdtWED2B1bHTNR5twmcdxhZfAjsosq2TH gigDwihdcmaAUTuYXhGJ0fJvPiFq346ufv/hPK4LkNrsE4TF4Iba8Vo6i5iyo9R/ bx6C/sHx/g5FboiY/bQiUIeWsCM75XgGcLZp1pdOunYx1FHPykcqlnBPRaErr2q0 5iRAVdYUqR+PHwzOeQpojV/Iy6pD9145TNNNi99wdi9eCcTMO9AiWu0X/CGDwWlr m+TXsnrCaFBTdaiu6KE1pVmD43QVgG7RL1hNNyK/eBsRNWwVFCn2dmntqhFLc/uq RyqVzCzN14IoEdRbVPdHPPoO3odKumwCWU4fiu03ScwsSrFMkpE5kgDMrHXx6vrF AAv1OLa3uDpCEBPdgS3ENfv+jeXhUVIhdeSRegB+JYNjw/L5bOs =t0bw -----END PGP SIGNATURE----- --Signature=_Fri__17_Mar_2017_10_34_27_+0100_frEBnf6J4Nll4wC7--
Fri, 17 Mar 2017 10:26:49 +0100
Olivier <oza.4h07@gmail.com> écrivait :
salut,
$ sudo apt-get -s dist-upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus
nécessaires :
bijiben libsofia-sip-ua-glib3 libsofia-sip-ua0 telepathy-rakia
Veuillez utiliser « sudo apt autoremove » pour les supprimer.
Les NOUVEAUX paquets suivants seront installés :
firmware-linux-free gnome-calendar irqbalance libopenmpt0 libpgm-5.2-0
libproxy1-plugin-gsettings
libproxy1-plugin-networkmanager libsaxonhe-java
linux-image-4.9.0-2-686-pae
Les paquets suivants seront mis à jour :
gnome gnome-core gstreamer1.0-libav libavdevice57 libavfilter6
libavformat57 libgegl-0.3-0 libopencv-calib3d2.4v5
libopencv-core2.4v5 libopencv-features2d2.4v5 libopencv-flann2.4v5
libopencv-highgui2.4-deb0 libopencv-imgproc2.4v5
libopencv-objdetect2.4v5 libopencv-video2.4v5 libxmlbeans-java libzmq5
linux-image-686-pae
18 mis à jour, 9 nouvellement installés, 0 à enlever et 0 non mis à jour.
Si j'en crois ce qui précède, linux-image n'est pas mis à jour par
dist-upgrade.
Si tu regardes attentivement, tu verras linux-image-686-pae dans la liste d es paquets qui seront mis à jour et linux-image-4.9.0-2-686-pae dans l a liste des nouveaux paquets.
$ sudo apt-get -s dist-upgrade Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Calcul de la mise à jour... Fait Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires : bijiben libsofia-sip-ua-glib3 libsofia-sip-ua0 telepathy-rakia Veuillez utiliser « sudo apt autoremove » pour les supprimer. Les NOUVEAUX paquets suivants seront installés : firmware-linux-free gnome-calendar irqbalance libopenmpt0 libpgm-5.2-0 libproxy1-plugin-gsettings libproxy1-plugin-networkmanager libsaxonhe-java linux-image-4.9.0-2-686-pae Les paquets suivants seront mis à jour : gnome gnome-core gstreamer1.0-libav libavdevice57 libavfilter6 libavformat57 libgegl-0.3-0 libopencv-calib3d2.4v5 libopencv-core2.4v5 libopencv-features2d2.4v5 libopencv-flann2.4v5 libopencv-highgui2.4-deb0 libopencv-imgproc2.4v5 libopencv-objdetect2.4v5 libopencv-video2.4v5 libxmlbeans-java libzmq5 linux-image-686-pae 18 mis à jour, 9 nouvellement installés, 0 à enlever et 0 non mis à jour. Si j'en crois ce qui précède, linux-image n'est pas mis à jour par dist-upgrade.
Si tu regardes attentivement, tu verras linux-image-686-pae dans la liste d es paquets qui seront mis à jour et linux-image-4.9.0-2-686-pae dans l a liste des nouveaux paquets. Je pensais que c'est ce que tu voulais. Jean-Marc --Signature=_Fri__17_Mar_2017_10_34_27_+0100_frEBnf6J4Nll4wC7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEEWjgcRC0dCXkfm9hQHHLXC3pxPwFAljLraMACgkQQHHLXC3p xPw4Dg/9FRhPnObIkJ+Il1vksgO3QQN1HDVbVA2F+0UHWeaf9wW5vUAUH5GDWb+4 y8Hdbu+J1f7+YuSSPWZbCipQK6U/aJBVUp7L8VV0Ryy+ng2qHK6pp6xn7KZHzDqD /GltckpPtWBA2mT1jy5F5MYuThigfNjzG53LwffGI1v4ooV/O1gOJp5zTpl3oXs7 8pUQEHL6+0qf/WWzae4/FGIXo1o3bppF1JYJwI3PjU+5zGmbxHLQWEzWc8j6u+t9 Pvxj2j8SXLfHYRdi5dKe5Q3M+jy/EC/YdtWED2B1bHTNR5twmcdxhZfAjsosq2TH gigDwihdcmaAUTuYXhGJ0fJvPiFq346ufv/hPK4LkNrsE4TF4Iba8Vo6i5iyo9R/ bx6C/sHx/g5FboiY/bQiUIeWsCM75XgGcLZp1pdOunYx1FHPykcqlnBPRaErr2q0 5iRAVdYUqR+PHwzOeQpojV/Iy6pD9145TNNNi99wdi9eCcTMO9AiWu0X/CGDwWlr m+TXsnrCaFBTdaiu6KE1pVmD43QVgG7RL1hNNyK/eBsRNWwVFCn2dmntqhFLc/uq RyqVzCzN14IoEdRbVPdHPPoO3odKumwCWU4fiu03ScwsSrFMkpE5kgDMrHXx6vrF AAv1OLa3uDpCEBPdgS3ENfv+jeXhUVIhdeSRegB+JYNjw/L5bOs =t0bw -----END PGP SIGNATURE----- --Signature=_Fri__17_Mar_2017_10_34_27_+0100_frEBnf6J4Nll4wC7--
