************************************************************************
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
Version 2, December 2004
Copyright (C) 2004 Sam Hocevar <sam@hocevar.net>
Everyone is permitted to copy and distribute verbatim or modified
copies of this license document, and changing it is allowed as long
as the name is changed.
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. You just DO WHAT THE FUCK YOU WANT TO.
************************************************************************
[Also posted chez les barbus trolleurs et chez les techno-crétins]
J'avais pété (enfin... je suppose que c'est moi le coupable...) le
Windows Update de mon OuinOuin Saiveun Familial Prêmiôm Edicheun.
Notez bien que l'affaire ne me traumatisait pas plus que ça. Je me
disais juste qu'à force de le monter sous Linux, le NTFS de la bouze
avait dû chopper ses vapeurs (c'est susceptible, ces merdes-là).
Bref, ce soir, j'ai passé un petit quart d'heure à googliser l'affaire
et voilà ce qui a résolu le problème :
* Ouvrir 'commande MS-DOS' en tant qu'administrateur ;
* lancer la commande 'SFC /SCANNOW' ;
* patienter un quart d'heure.
Pourquoi je poste sur fcold : parce que je rêve de faire partie de la
secte des vieux cons.
Pourquoi je poste sur fcomw : parce que ça fait longtemps que je n'étais
pas allé faire chier ces sales cons de techno-crétins.
Vous pouvez reprendre une activité normale.
--
> J'avais envisagé de changer la police que j'utilise dans mes terminaux, mais
> j'en suis revenu, parce que le temps d'ouverture du terminal était passé de
> 0,07 s à 0,2 s environ, et ça perturbait mes habitudes.
Je vois que tu t'attaches à résoudre des problèmes importants dans ta vie.
C'est vrai que ce n'est pas sous Linux que le gestionnaire de paquets ferait ce genre de chose, et proposerait par exemple des options genre "--fix-broken"
Pratique quand le courant tombe lorsqu'on met à jour un système. Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah, on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"? Parce que dans les deux cas, la commande répare la base de données des applications installées pour la remettre dans un état cohérent. (...)
ou "--force-yes", tout en disant que "Il est possible que
Effectivement, ce n'est pas une bonne pratique d'utiliser ce genre d'options. Mais un système qui ne les aurait pas, forcerait peut-être les petits bricoleurs à éditer directement les fichiers.
C'est surtout que les concepteurs ont prévu que leur système pourrait potentiellement merdoyer et ont prévu des portes de sorties "au cas où", alors se répandre sur un système qui, justement, a merdoyé... (...)
Comme quoi Linux, c'est tellement mieux...
Clairement. Mais encore faut-il investir sur la formation, et réfléchir avant de taper RETURN ou de s'encoubler (helvétisme) sur le cordon électrique.
C'est marrant: remplace "Linux" par "Windows", et ça marche aussi... ;-)
Le 10/09/16 à 17:08, Marc SCHAEFER a écrit :
Jerome Lambert <jerome@jlambert.be> wrote:
C'est vrai que ce n'est pas sous Linux que le gestionnaire de paquets
ferait ce genre de chose, et proposerait par exemple des options genre
"--fix-broken"
Pratique quand le courant tombe lorsqu'on met à jour un système.
Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah,
on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"?
Parce que dans les deux cas, la commande répare la base de données des
applications installées pour la remettre dans un état cohérent.
(...)
ou "--force-yes", tout en disant que "Il est possible que
Effectivement, ce n'est pas une bonne pratique d'utiliser ce genre
d'options. Mais un système qui ne les aurait pas, forcerait
peut-être les petits bricoleurs à éditer directement les fichiers.
C'est surtout que les concepteurs ont prévu que leur système pourrait
potentiellement merdoyer et ont prévu des portes de sorties "au cas où",
alors se répandre sur un système qui, justement, a merdoyé...
(...)
Comme quoi Linux, c'est tellement mieux...
Clairement. Mais encore faut-il investir sur la formation, et
réfléchir avant de taper RETURN ou de s'encoubler (helvétisme)
sur le cordon électrique.
C'est marrant: remplace "Linux" par "Windows", et ça marche aussi... ;-)
C'est vrai que ce n'est pas sous Linux que le gestionnaire de paquets ferait ce genre de chose, et proposerait par exemple des options genre "--fix-broken"
Pratique quand le courant tombe lorsqu'on met à jour un système. Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah, on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"? Parce que dans les deux cas, la commande répare la base de données des applications installées pour la remettre dans un état cohérent. (...)
ou "--force-yes", tout en disant que "Il est possible que
Effectivement, ce n'est pas une bonne pratique d'utiliser ce genre d'options. Mais un système qui ne les aurait pas, forcerait peut-être les petits bricoleurs à éditer directement les fichiers.
C'est surtout que les concepteurs ont prévu que leur système pourrait potentiellement merdoyer et ont prévu des portes de sorties "au cas où", alors se répandre sur un système qui, justement, a merdoyé... (...)
Comme quoi Linux, c'est tellement mieux...
Clairement. Mais encore faut-il investir sur la formation, et réfléchir avant de taper RETURN ou de s'encoubler (helvétisme) sur le cordon électrique.
C'est marrant: remplace "Linux" par "Windows", et ça marche aussi... ;-)
Marc SCHAEFER
Jerome Lambert wrote:
Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah, on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"?
Techniquement, Debian va reprendre l'installation où elle en était (idem-potente). On ne parle pas tout à fait de la même chose ici: il ne s'agit pas de `remettre la base de données en état', mais de poursuivre une installation interrompue.
Clairement. Mais encore faut-il investir sur la formation, et réfléchir avant de taper RETURN ou de s'encoubler (helvétisme) sur le cordon électrique.
C'est marrant: remplace "Linux" par "Windows", et ça marche aussi... ;-)
Pas tout à fait: le niveau de compréhension, avec les systèmes Microsoft, est toujours potentiellement moins profond, comme il s'agit d'un système fermé. Mais vous avez raison que, généralement, le problème fondamental est la formation, que cela soit sur les systèmes fermés ou les sytèmes ouverts et/ou libres.
Jerome Lambert <jerome@jlambert.be> wrote:
Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah,
on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"?
Techniquement, Debian va reprendre l'installation où elle en
était (idem-potente). On ne parle pas tout à fait de la même
chose ici: il ne s'agit pas de `remettre la base de données
en état', mais de poursuivre une installation interrompue.
Clairement. Mais encore faut-il investir sur la formation, et
réfléchir avant de taper RETURN ou de s'encoubler (helvétisme)
sur le cordon électrique.
C'est marrant: remplace "Linux" par "Windows", et ça marche aussi... ;-)
Pas tout à fait: le niveau de compréhension, avec les systèmes Microsoft,
est toujours potentiellement moins profond, comme il s'agit d'un
système fermé.
Mais vous avez raison que, généralement, le problème fondamental est
la formation, que cela soit sur les systèmes fermés ou les sytèmes
ouverts et/ou libres.
Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah, on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"?
Techniquement, Debian va reprendre l'installation où elle en était (idem-potente). On ne parle pas tout à fait de la même chose ici: il ne s'agit pas de `remettre la base de données en état', mais de poursuivre une installation interrompue.
Clairement. Mais encore faut-il investir sur la formation, et réfléchir avant de taper RETURN ou de s'encoubler (helvétisme) sur le cordon électrique.
C'est marrant: remplace "Linux" par "Windows", et ça marche aussi... ;-)
Pas tout à fait: le niveau de compréhension, avec les systèmes Microsoft, est toujours potentiellement moins profond, comme il s'agit d'un système fermé. Mais vous avez raison que, généralement, le problème fondamental est la formation, que cela soit sur les systèmes fermés ou les sytèmes ouverts et/ou libres.
Marc SCHAEFER
Jerome Lambert wrote:
Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah, on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"?
Techniquement, Debian va reprendre l'installation où elle en était (idem-potente). On ne parle pas tout à fait de la même chose ici: il ne s'agit pas de `remettre la base de données en état', mais de poursuivre une installation interrompue.
Clairement. Mais encore faut-il investir sur la formation, et réfléchir avant de taper RETURN ou de s'encoubler (helvétisme) sur le cordon électrique.
C'est marrant: remplace "Linux" par "Windows", et ça marche aussi... ;-)
Pas tout à fait: le niveau de compréhension, avec les systèmes Microsoft, est toujours potentiellement moins profond, comme il s'agit d'un système fermé. Mais vous avez raison que, généralement, le problème fondamental est la formation, que cela soit sur les systèmes fermés ou les systèmes ouverts et/ou libres.
Jerome Lambert <jerome@jlambert.be> wrote:
Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah,
on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"?
Techniquement, Debian va reprendre l'installation où elle en
était (idem-potente). On ne parle pas tout à fait de la même
chose ici: il ne s'agit pas de `remettre la base de données
en état', mais de poursuivre une installation interrompue.
Clairement. Mais encore faut-il investir sur la formation, et
réfléchir avant de taper RETURN ou de s'encoubler (helvétisme)
sur le cordon électrique.
C'est marrant: remplace "Linux" par "Windows", et ça marche aussi... ;-)
Pas tout à fait: le niveau de compréhension, avec les systèmes Microsoft,
est toujours potentiellement moins profond, comme il s'agit d'un
système fermé.
Mais vous avez raison que, généralement, le problème fondamental est
la formation, que cela soit sur les systèmes fermés ou les systèmes
ouverts et/ou libres.
Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah, on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"?
Techniquement, Debian va reprendre l'installation où elle en était (idem-potente). On ne parle pas tout à fait de la même chose ici: il ne s'agit pas de `remettre la base de données en état', mais de poursuivre une installation interrompue.
Clairement. Mais encore faut-il investir sur la formation, et réfléchir avant de taper RETURN ou de s'encoubler (helvétisme) sur le cordon électrique.
C'est marrant: remplace "Linux" par "Windows", et ça marche aussi... ;-)
Pas tout à fait: le niveau de compréhension, avec les systèmes Microsoft, est toujours potentiellement moins profond, comme il s'agit d'un système fermé. Mais vous avez raison que, généralement, le problème fondamental est la formation, que cela soit sur les systèmes fermés ou les systèmes ouverts et/ou libres.
Jerome Lambert
Le 10/09/16 à 18:07, Marc SCHAEFER a écrit :
Jerome Lambert wrote:
Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah, on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"?
Techniquement, Debian va reprendre l'installation où elle en était (idem-potente). On ne parle pas tout à fait de la même chose ici: il ne s'agit pas de `remettre la base de données en état', mais de poursuivre une installation interrompue.
Euuuuh, ce n'est pas ce que dit le man... "-f, --fix-broken Correction ; cette option demande de réparer un système où existent des dépendances défectueuses. Utilisée avec install ou remove, elle peut exclure un paquet pour permettre de déduire une solution viable. Tout paquet spécifié doit complètement corriger le problème. Cette option est quelquefois nécessaire lorsque l'on exécute APT pour la première fois ; APT interdit les dépendances défectueuses dans un système. Il est possible que la structure de dépendances d'un système soit tellement corrompue qu'elle requiert une intervention manuelle (ce qui veut dire la plupart du temps utiliser dpkg --remove pour éliminer les paquets en cause). L'utilisation de cette option conjointement avec -m peut produire une erreur dans certaines situations."
Le 10/09/16 à 18:07, Marc SCHAEFER a écrit :
Jerome Lambert <jerome@jlambert.be> wrote:
Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah,
on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"?
Techniquement, Debian va reprendre l'installation où elle en
était (idem-potente). On ne parle pas tout à fait de la même
chose ici: il ne s'agit pas de `remettre la base de données
en état', mais de poursuivre une installation interrompue.
Euuuuh, ce n'est pas ce que dit le man...
"-f, --fix-broken
Correction ; cette option demande de réparer un système où existent des
dépendances défectueuses. Utilisée avec install ou remove, elle peut
exclure un paquet pour permettre de déduire une solution viable. Tout
paquet spécifié doit complètement corriger le problème. Cette option est
quelquefois nécessaire lorsque l'on exécute APT pour la première fois ;
APT interdit les dépendances défectueuses dans un système. Il est
possible que la structure de dépendances d'un système soit tellement
corrompue qu'elle requiert une intervention manuelle (ce qui veut dire
la plupart du temps utiliser dpkg --remove pour éliminer les paquets en
cause). L'utilisation de cette option conjointement avec -m peut
produire une erreur dans certaines situations."
Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah, on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"?
Techniquement, Debian va reprendre l'installation où elle en était (idem-potente). On ne parle pas tout à fait de la même chose ici: il ne s'agit pas de `remettre la base de données en état', mais de poursuivre une installation interrompue.
Euuuuh, ce n'est pas ce que dit le man... "-f, --fix-broken Correction ; cette option demande de réparer un système où existent des dépendances défectueuses. Utilisée avec install ou remove, elle peut exclure un paquet pour permettre de déduire une solution viable. Tout paquet spécifié doit complètement corriger le problème. Cette option est quelquefois nécessaire lorsque l'on exécute APT pour la première fois ; APT interdit les dépendances défectueuses dans un système. Il est possible que la structure de dépendances d'un système soit tellement corrompue qu'elle requiert une intervention manuelle (ce qui veut dire la plupart du temps utiliser dpkg --remove pour éliminer les paquets en cause). L'utilisation de cette option conjointement avec -m peut produire une erreur dans certaines situations."
Marc SCHAEFER
In article you wrote:
Euuuuh, ce n'est pas ce que dit le man...
C'est pourtant, en pratique à ce que cela sert. Je ne crois pas me rappeler l'avoir utilisée pour réparer une `base de données défectueuse on ne sait pas trop pourquoi' [4] comme vous avez mentionné pour la commande Microsoft. Debian maintient un état de paquets (visible par dpkg -s) qui indique non seulement si un paquet est installé, mais aussi son état désiré (par exemple: j'ai envie de l'installer, j'ai envie de le supprimer, il est entrain d'être supprimé, il reste ou non ses fichiers de configuration, etc). De plus, les scripts d'installations et de déinstallation sont censés [5] être idem-potents (2 exécutions complètes ou partielles produisent le même résultat sur le système). Ce qui permet en cas d'interruption volontaire ou non d'une installation ou d'une mise à jour de reprendre où l'on était. La preuve, ça marche même après une coupure de courant [1]. Cela peut aussi servir à reprendre une installation logicielle suite à une défectuosité logicielle (un paquet dont le script d'installation contient un bug, par exemple une dépendance non exprimée explicitement[2]), effectivement, mais cela n'arrive pas très souvent dans mon expérience. Cela peut arriver si l'on a installé des packages manuellement en plus de ceux supportées par les sources d'installation: dans ce cas, aptitude permet facilement de localiser les `Locally installed'. Dans des cas horribles (genre script de déinstallation qui plante, deux packages avec la volonté d'installer les mêmes fichiers), une intervention manuelle sera effectivement nécessaire, mais l'erreur présentée est très claire et identifie à coup sûr le paquet en erreur, à mon avis. Un cas où cela pourrait vraiment planter c'est si on a installé un fichier manuellement dans le système (p.ex. dans /usr/bin plutôt que /usr/local/bin), et là on rejoint la question déjà mentionnée de la formation. La solution sera soit de faire une diversion (dpkg-divert(8)) avant de relancer `apt-get install -f' ou de déplacer le logiciel installé manuellement. Par exemple, j'aime bien avoir des versions très récentes de Firefox, j'ai donc installé ces différentes versions dans /usr/local/FIREFOX-${VERSION} et j'ai ajouté une diversion: :~$ dpkg-divert --list | grep firefox | tail -1 local diversion of /usr/bin/firefox-esr to /usr/bin/firefox-esr.distrib qui me permet de jouer avec des liens symboliques pour définir la version réellement active de Firefox pour tout le système: 48.0.2, ESR, 37.0, etc. Effectivement, les distributions non basées `dpkg/APT' comme Red Hat n'ont pas ce degré de sophistication. La conception de Debian ainsi que les aspects communautaires de ce projet sont vraiment étonnants! On doit toutefois constater [6] que l'informatique semble se déplacer vers un concept d'applications autocontenues, avec p.ex. les packages Docker, où l'on n'installe plus grand chose, mais l'on crée des machines virtuelles légères (containers UNIX, chroot(8) amélioré). L'idée de mise à jour à très long terme [3] va gentiment disparaître, avec la valeur ajoutée de Debian, si ce concept se développe réellement dans tous les cas d'utilisation de Debian. Microsoft a bien compris l'intérêt et a porté UNIX bash et Docker vers sa plateforme (toutefois sans réellement implémenter de vrais containers à la UNIX, mais des machines virtuelles lourdes, style kvm, pour le moment, à ma connaissance, basées sur Microsoft HyperV). [1] je peux imaginer des cas où cela ne marcherait pas, par exemple si le disque a des `bad blocks' suite à l'arrêt involontaire de l'alimentation [2] rencontré extrêmement rarement en 18 ans d'utilisation de Debian (ok, argument moisi) [3] p.ex. j'ai un serveur en container Debian installé en 2003 que je mets à jour tous les N années en fonction du cycle de release Debian et nouvellement LTS -- d'ailleurs au départ c'était une vrai machine, `containerizée' par la suite. [4] si on corrompt certains fichiers de BD de dpkg ou APT, je pense qu'il vaut mieux restaurer des backups: je n'ai pas d'expérience dans ce domaine (jamais arrivé). [5] https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html section 6.2 "It is necessary for the error recovery procedures that the scripts be idempotent" [6] voire regretter, vu l'effort investi par les développeurs Debian!
In article <e3k7mfFsb99U1@mid.individual.net> you wrote:
Euuuuh, ce n'est pas ce que dit le man...
C'est pourtant, en pratique à ce que cela sert. Je ne crois pas me rappeler
l'avoir utilisée pour réparer une `base de données défectueuse on ne sait pas
trop pourquoi' [4] comme vous avez mentionné pour la commande Microsoft.
Debian maintient un état de paquets (visible par dpkg -s) qui indique non
seulement si un paquet est installé, mais aussi son état désiré (par exemple:
j'ai envie de l'installer, j'ai envie de le supprimer, il est entrain d'être
supprimé, il reste ou non ses fichiers de configuration, etc). De plus,
les scripts d'installations et de déinstallation sont censés [5] être
idem-potents (2 exécutions complètes ou partielles produisent le même résultat
sur le système).
Ce qui permet en cas d'interruption volontaire ou non d'une installation
ou d'une mise à jour de reprendre où l'on était. La preuve, ça marche même
après une coupure de courant [1].
Cela peut aussi servir à reprendre une installation logicielle suite à une
défectuosité logicielle (un paquet dont le script d'installation contient
un bug, par exemple une dépendance non exprimée explicitement[2]),
effectivement, mais cela n'arrive pas très souvent dans mon expérience.
Cela peut arriver si l'on a installé des packages manuellement en plus
de ceux supportées par les sources d'installation: dans ce cas, aptitude
permet facilement de localiser les `Locally installed'. Dans des cas
horribles (genre script de déinstallation qui plante, deux packages avec
la volonté d'installer les mêmes fichiers), une intervention
manuelle sera effectivement nécessaire, mais l'erreur présentée est
très claire et identifie à coup sûr le paquet en erreur, à mon avis.
Un cas où cela pourrait vraiment planter c'est si on a installé un fichier
manuellement dans le système (p.ex. dans /usr/bin plutôt que /usr/local/bin),
et là on rejoint la question déjà mentionnée de la formation. La solution
sera soit de faire une diversion (dpkg-divert(8)) avant de relancer
`apt-get install -f' ou de déplacer le logiciel installé manuellement.
Par exemple, j'aime bien avoir des versions très récentes de Firefox,
j'ai donc installé ces différentes versions dans /usr/local/FIREFOX-${VERSION}
et j'ai ajouté une diversion:
schaefer@reliand:~$ dpkg-divert --list | grep firefox | tail -1
local diversion of /usr/bin/firefox-esr to /usr/bin/firefox-esr.distrib
qui me permet de jouer avec des liens symboliques pour définir la
version réellement active de Firefox pour tout le système: 48.0.2,
ESR, 37.0, etc.
Effectivement, les distributions non basées `dpkg/APT' comme Red Hat
n'ont pas ce degré de sophistication. La conception de Debian ainsi que
les aspects communautaires de ce projet sont vraiment étonnants!
On doit toutefois constater [6] que l'informatique semble se déplacer vers
un concept d'applications autocontenues, avec p.ex. les packages
Docker, où l'on n'installe plus grand chose, mais l'on crée des machines
virtuelles légères (containers UNIX, chroot(8) amélioré). L'idée
de mise à jour à très long terme [3] va gentiment disparaître, avec
la valeur ajoutée de Debian, si ce concept se développe réellement
dans tous les cas d'utilisation de Debian.
Microsoft a bien compris l'intérêt et a porté UNIX bash et Docker vers sa
plateforme (toutefois sans réellement implémenter de vrais containers à la
UNIX, mais des machines virtuelles lourdes, style kvm, pour le moment, à ma
connaissance, basées sur Microsoft HyperV).
[1] je peux imaginer des cas où cela ne marcherait pas, par exemple si le
disque a des `bad blocks' suite à l'arrêt involontaire de l'alimentation
[2] rencontré extrêmement rarement en 18 ans d'utilisation de Debian
(ok, argument moisi)
[3] p.ex. j'ai un serveur en container Debian installé en 2003 que je mets
à jour tous les N années en fonction du cycle de release Debian et
nouvellement LTS -- d'ailleurs au départ c'était une vrai machine,
`containerizée' par la suite.
[4] si on corrompt certains fichiers de BD de dpkg ou APT, je pense qu'il
vaut mieux restaurer des backups: je n'ai pas d'expérience dans
ce domaine (jamais arrivé).
[5] https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
section 6.2 "It is necessary for the error recovery procedures that
the scripts be idempotent"
[6] voire regretter, vu l'effort investi par les développeurs Debian!
C'est pourtant, en pratique à ce que cela sert. Je ne crois pas me rappeler l'avoir utilisée pour réparer une `base de données défectueuse on ne sait pas trop pourquoi' [4] comme vous avez mentionné pour la commande Microsoft. Debian maintient un état de paquets (visible par dpkg -s) qui indique non seulement si un paquet est installé, mais aussi son état désiré (par exemple: j'ai envie de l'installer, j'ai envie de le supprimer, il est entrain d'être supprimé, il reste ou non ses fichiers de configuration, etc). De plus, les scripts d'installations et de déinstallation sont censés [5] être idem-potents (2 exécutions complètes ou partielles produisent le même résultat sur le système). Ce qui permet en cas d'interruption volontaire ou non d'une installation ou d'une mise à jour de reprendre où l'on était. La preuve, ça marche même après une coupure de courant [1]. Cela peut aussi servir à reprendre une installation logicielle suite à une défectuosité logicielle (un paquet dont le script d'installation contient un bug, par exemple une dépendance non exprimée explicitement[2]), effectivement, mais cela n'arrive pas très souvent dans mon expérience. Cela peut arriver si l'on a installé des packages manuellement en plus de ceux supportées par les sources d'installation: dans ce cas, aptitude permet facilement de localiser les `Locally installed'. Dans des cas horribles (genre script de déinstallation qui plante, deux packages avec la volonté d'installer les mêmes fichiers), une intervention manuelle sera effectivement nécessaire, mais l'erreur présentée est très claire et identifie à coup sûr le paquet en erreur, à mon avis. Un cas où cela pourrait vraiment planter c'est si on a installé un fichier manuellement dans le système (p.ex. dans /usr/bin plutôt que /usr/local/bin), et là on rejoint la question déjà mentionnée de la formation. La solution sera soit de faire une diversion (dpkg-divert(8)) avant de relancer `apt-get install -f' ou de déplacer le logiciel installé manuellement. Par exemple, j'aime bien avoir des versions très récentes de Firefox, j'ai donc installé ces différentes versions dans /usr/local/FIREFOX-${VERSION} et j'ai ajouté une diversion: :~$ dpkg-divert --list | grep firefox | tail -1 local diversion of /usr/bin/firefox-esr to /usr/bin/firefox-esr.distrib qui me permet de jouer avec des liens symboliques pour définir la version réellement active de Firefox pour tout le système: 48.0.2, ESR, 37.0, etc. Effectivement, les distributions non basées `dpkg/APT' comme Red Hat n'ont pas ce degré de sophistication. La conception de Debian ainsi que les aspects communautaires de ce projet sont vraiment étonnants! On doit toutefois constater [6] que l'informatique semble se déplacer vers un concept d'applications autocontenues, avec p.ex. les packages Docker, où l'on n'installe plus grand chose, mais l'on crée des machines virtuelles légères (containers UNIX, chroot(8) amélioré). L'idée de mise à jour à très long terme [3] va gentiment disparaître, avec la valeur ajoutée de Debian, si ce concept se développe réellement dans tous les cas d'utilisation de Debian. Microsoft a bien compris l'intérêt et a porté UNIX bash et Docker vers sa plateforme (toutefois sans réellement implémenter de vrais containers à la UNIX, mais des machines virtuelles lourdes, style kvm, pour le moment, à ma connaissance, basées sur Microsoft HyperV). [1] je peux imaginer des cas où cela ne marcherait pas, par exemple si le disque a des `bad blocks' suite à l'arrêt involontaire de l'alimentation [2] rencontré extrêmement rarement en 18 ans d'utilisation de Debian (ok, argument moisi) [3] p.ex. j'ai un serveur en container Debian installé en 2003 que je mets à jour tous les N années en fonction du cycle de release Debian et nouvellement LTS -- d'ailleurs au départ c'était une vrai machine, `containerizée' par la suite. [4] si on corrompt certains fichiers de BD de dpkg ou APT, je pense qu'il vaut mieux restaurer des backups: je n'ai pas d'expérience dans ce domaine (jamais arrivé). [5] https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html section 6.2 "It is necessary for the error recovery procedures that the scripts be idempotent" [6] voire regretter, vu l'effort investi par les développeurs Debian!
*.pipolin.*
Tonton Th a émis l'idée suivante :
On 2016-09-09, Hugolino wrote:
Pourquoi je poste sur fcold : parce que je rêve de faire partie de la secte des vieux cons.
Cette année, c'est pipolin qui encaisse les cotisations.
Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah, on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"?
Techniquement, Debian va reprendre l'installation où elle en était (idem-potente). On ne parle pas tout à fait de la même chose ici: il ne s'agit pas de `remettre la base de données en état', mais de poursuivre une installation interrompue.
Clairement. Mais encore faut-il investir sur la formation, et réfléchir avant de taper RETURN ou de s'encoubler (helvétisme) sur le cordon électrique.
C'est marrant: remplace "Linux" par "Windows", et ça marche aussi... ;-)
Pas tout à fait: le niveau de compréhension, avec les systèmes Microsoft, est toujours potentiellement moins profond, comme il s'agit d'un système fermé.
Si il faut aller lire le code source pour comprendre ce qui se passe, c'est que la doc est moisie...
Mais vous avez raison que, généralement, le problème fondamental est la formation, que cela soit sur les systèmes fermés ou les sytèmes ouverts et/ou libres.
Le 10/09/2016 à 18:06, Marc SCHAEFER a écrit :
Jerome Lambert <jerome@jlambert.be> wrote:
Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah,
on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"?
Techniquement, Debian va reprendre l'installation où elle en
était (idem-potente). On ne parle pas tout à fait de la même
chose ici: il ne s'agit pas de `remettre la base de données
en état', mais de poursuivre une installation interrompue.
Clairement. Mais encore faut-il investir sur la formation, et
réfléchir avant de taper RETURN ou de s'encoubler (helvétisme)
sur le cordon électrique.
C'est marrant: remplace "Linux" par "Windows", et ça marche aussi... ;-)
Pas tout à fait: le niveau de compréhension, avec les systèmes Microsoft,
est toujours potentiellement moins profond, comme il s'agit d'un
système fermé.
Si il faut aller lire le code source pour comprendre ce qui se passe,
c'est que la doc est moisie...
Mais vous avez raison que, généralement, le problème fondamental est
la formation, que cela soit sur les systèmes fermés ou les sytèmes
ouverts et/ou libres.
Par exemple sous Debian, cela m'est arrivé la semaine passée. Bah, on redémarre, on fait apt-get install -f et en général c'est bon.
Et quelle est la différence avec un "SFC /SCANNOW"?
Techniquement, Debian va reprendre l'installation où elle en était (idem-potente). On ne parle pas tout à fait de la même chose ici: il ne s'agit pas de `remettre la base de données en état', mais de poursuivre une installation interrompue.
Clairement. Mais encore faut-il investir sur la formation, et réfléchir avant de taper RETURN ou de s'encoubler (helvétisme) sur le cordon électrique.
C'est marrant: remplace "Linux" par "Windows", et ça marche aussi... ;-)
Pas tout à fait: le niveau de compréhension, avec les systèmes Microsoft, est toujours potentiellement moins profond, comme il s'agit d'un système fermé.
Si il faut aller lire le code source pour comprendre ce qui se passe, c'est que la doc est moisie...
Mais vous avez raison que, généralement, le problème fondamental est la formation, que cela soit sur les systèmes fermés ou les sytèmes ouverts et/ou libres.
Hugolino
On 2016-09-11, *.pipolin.* wrote:
Tonton Th a émis l'idée suivante :
On 2016-09-09, Hugolino wrote:
Pourquoi je poste sur fcold : parce que je rêve de faire partie de la secte des vieux cons.
Cette année, c'est pipolin qui encaisse les cotisations.
oue... Mais moi, chui pas vieux...
Mais comme tu es largement plus con que le plus con des VieuxCons, ça compense largement. -- Concours de bit entre linuxiens : hcgvzr Hugo (né il y a 1 653 124 165 secondes)
On 2016-09-11, *.pipolin.* <opipolino@DTC.com> wrote:
Tonton Th a émis l'idée suivante :
On 2016-09-09, Hugolino <hugolino@free.fr> wrote:
Pourquoi je poste sur fcold : parce que je rêve de faire partie de
la secte des vieux cons.
Cette année, c'est pipolin qui encaisse les cotisations.
oue...
Mais moi, chui pas vieux...
Mais comme tu es largement plus con que le plus con des VieuxCons, ça
compense largement.
--
Concours de bit entre linuxiens : hcgvzr
Hugo (né il y a 1 653 124 165 secondes)
Pourquoi je poste sur fcold : parce que je rêve de faire partie de la secte des vieux cons.
Cette année, c'est pipolin qui encaisse les cotisations.
oue... Mais moi, chui pas vieux...
Mais comme tu es largement plus con que le plus con des VieuxCons, ça compense largement. -- Concours de bit entre linuxiens : hcgvzr Hugo (né il y a 1 653 124 165 secondes)
*.pipolin.*
Le 12/09/2016, Hugolino a supposé :
On 2016-09-11, *.pipolin.* wrote:
Tonton Th a émis l'idée suivante :
On 2016-09-09, Hugolino wrote:
Pourquoi je poste sur fcold : parce que je rêve de faire partie de la secte des vieux cons.
Cette année, c'est pipolin qui encaisse les cotisations.
oue... Mais moi, chui pas vieux...
Mais comme tu es largement plus con que le plus con des VieuxCons, ça compense largement.
Si il faut aller lire le code source pour comprendre ce qui se passe, c'est que la doc est moisie...
Vous êtes bien limitatif. Et vous citez bizarrement. Il y a d'excellents tutoriaux sur l'administration système Linux, et Debian. Les éléments dont j'ai parlé y figurent. Il y a même un excellent bouquin chez Eyrolles. Bon, évidemment, ici c'est fr.comp.os.linux.debats ...
pehache <pehache.7@gmail.com> wrote:
Si il faut aller lire le code source pour comprendre ce qui se passe,
c'est que la doc est moisie...
Vous êtes bien limitatif. Et vous citez bizarrement.
Il y a d'excellents tutoriaux sur l'administration système Linux,
et Debian. Les éléments dont j'ai parlé y figurent. Il y a même
un excellent bouquin chez Eyrolles.
Bon, évidemment, ici c'est fr.comp.os.linux.debats ...
Si il faut aller lire le code source pour comprendre ce qui se passe, c'est que la doc est moisie...
Vous êtes bien limitatif. Et vous citez bizarrement. Il y a d'excellents tutoriaux sur l'administration système Linux, et Debian. Les éléments dont j'ai parlé y figurent. Il y a même un excellent bouquin chez Eyrolles. Bon, évidemment, ici c'est fr.comp.os.linux.debats ...
