Lorsque je connecte mon Palm, les modules nécessaires au transfert
(usbserial et visor) ne se chargent pas automatiquement, bien que le
système reconnaisse l'engin :
$ dmesg
[ 4725.976101] usb 1-2.1: new full-speed USB device number 9 using ehci-pci
[ 4726.085793] usb 1-2.1: New USB device found, idVendor=0830, idProduct=0061
[ 4726.085800] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[ 4726.085805] usb 1-2.1: Product: Palm Handheld
[ 4726.085811] usb 1-2.1: Manufacturer: PalmOne, Inc.
J'ai pallié au problème en chargeant les modules d'office au boot
(/etc/modules), mais par curiosité y a-t-il un moyen qui permettrait de ne
le charger que lors du branchement ?
Sinon, je suppose qu'on peut faire un rapport de bogue pour le noyau, mais
où cela se fait-il ?
Merci.
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Bonjour, Lorsque je connecte mon Palm, les modules nécessaires au transfert (usbserial et visor) ne se chargent pas automatiquement, bien que le système reconnaisse l'engin : $ dmesg [ 4725.976101] usb 1-2.1: new full-speed USB device number 9 using ehci-pci [ 4726.085793] usb 1-2.1: New USB device found, idVendor30, idProduct 61 [ 4726.085800] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [ 4726.085805] usb 1-2.1: Product: Palm Handheld [ 4726.085811] usb 1-2.1: Manufacturer: PalmOne, Inc. J'ai pallié au problème en chargeant les modules d'office au boot (/etc/modules), mais par curiosité y a-t-il un moyen qui permettrait de ne le charger que lors du branchement ?
Écrire une règle udev dans /etc/udev.d (l'emplacement dépend des distributions). Il faut mettre les identifiants du produit et dire (avec la syntaxe udev) quels modules charger.
Sinon, je suppose qu'on peut faire un rapport de bogue pour le noyau,
Je ne pense pas que ce soit un bogue: tous les zinzins qu'on branche ne sont pas répertoriés...
mais où cela se fait-il ?
Le site des rapports de bogues de la distribution utilisée. -- François Patte Université Paris Descartes
Le 06/09/2018 à 11:38, Lucas Levrel a écrit :
Bonjour,
Lorsque je connecte mon Palm, les modules nécessaires au transfert
(usbserial et visor) ne se chargent pas automatiquement, bien que le
système reconnaisse l'engin :
$ dmesg
[ 4725.976101] usb 1-2.1: new full-speed USB device number 9 using ehci-pci
[ 4726.085793] usb 1-2.1: New USB device found, idVendor30,
idProduct 61
[ 4726.085800] usb 1-2.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=5
[ 4726.085805] usb 1-2.1: Product: Palm Handheld
[ 4726.085811] usb 1-2.1: Manufacturer: PalmOne, Inc.
J'ai pallié au problème en chargeant les modules d'office au boot
(/etc/modules), mais par curiosité y a-t-il un moyen qui permettrait de
ne le charger que lors du branchement ?
Écrire une règle udev dans /etc/udev.d (l'emplacement dépend des
distributions). Il faut mettre les identifiants du produit et dire (avec
la syntaxe udev) quels modules charger.
Sinon, je suppose qu'on peut faire un rapport de bogue pour le noyau,
Je ne pense pas que ce soit un bogue: tous les zinzins qu'on branche ne
sont pas répertoriés...
mais où cela se fait-il ?
Le site des rapports de bogues de la distribution utilisée.
Bonjour, Lorsque je connecte mon Palm, les modules nécessaires au transfert (usbserial et visor) ne se chargent pas automatiquement, bien que le système reconnaisse l'engin : $ dmesg [ 4725.976101] usb 1-2.1: new full-speed USB device number 9 using ehci-pci [ 4726.085793] usb 1-2.1: New USB device found, idVendor30, idProduct 61 [ 4726.085800] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [ 4726.085805] usb 1-2.1: Product: Palm Handheld [ 4726.085811] usb 1-2.1: Manufacturer: PalmOne, Inc. J'ai pallié au problème en chargeant les modules d'office au boot (/etc/modules), mais par curiosité y a-t-il un moyen qui permettrait de ne le charger que lors du branchement ?
Écrire une règle udev dans /etc/udev.d (l'emplacement dépend des distributions). Il faut mettre les identifiants du produit et dire (avec la syntaxe udev) quels modules charger.
Sinon, je suppose qu'on peut faire un rapport de bogue pour le noyau,
Je ne pense pas que ce soit un bogue: tous les zinzins qu'on branche ne sont pas répertoriés...
mais où cela se fait-il ?
Le site des rapports de bogues de la distribution utilisée. -- François Patte Université Paris Descartes
Lucas Levrel
Le 6 septembre 2018, à 11:38, Lucas Levrel a écrit :
Lorsque je connecte mon Palm, les modules nécessaires au transfert (usbserial et visor) ne se chargent pas automatiquement, bien que le système reconnaisse l'engin :
J'avais trouvé la solution mais oublié de la poster... mieux vaut tard que jamais : le module visor était blacklisté dans un fichier de conf sous /etc/modprobe.d ! Ligne commentée, problème disparu. -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 6 septembre 2018, à 11:38, Lucas Levrel a écrit :
Lorsque je connecte mon Palm, les modules nécessaires au transfert (usbserial
et visor) ne se chargent pas automatiquement, bien que le système reconnaisse
l'engin :
J'avais trouvé la solution mais oublié de la poster... mieux vaut tard que
jamais : le module visor était blacklisté dans un fichier de conf sous
/etc/modprobe.d ! Ligne commentée, problème disparu.
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Le 6 septembre 2018, à 11:38, Lucas Levrel a écrit :
Lorsque je connecte mon Palm, les modules nécessaires au transfert (usbserial et visor) ne se chargent pas automatiquement, bien que le système reconnaisse l'engin :
J'avais trouvé la solution mais oublié de la poster... mieux vaut tard que jamais : le module visor était blacklisté dans un fichier de conf sous /etc/modprobe.d ! Ligne commentée, problème disparu. -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Pierre www.aribaut.com
Le 18/12/2018 à 17:59, Lucas Levrel a écrit :
Le 6 septembre 2018, à 11:38, Lucas Levrel a écrit :
Lorsque je connecte mon Palm, les modules nécessaires au transfert (usbserial et visor) ne se chargent pas automatiquement, bien que le système reconnaisse l'engin :
J'avais trouvé la solution mais oublié de la poster... mieux vaut tard que jamais : le module visor était blacklisté dans un fichier de conf sous /etc/modprobe.d ! Ligne commentée, problème disparu.
Ça peut se blacklister tout seul un module ? -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 18/12/2018 à 17:59, Lucas Levrel a écrit :
Le 6 septembre 2018, à 11:38, Lucas Levrel a écrit :
Lorsque je connecte mon Palm, les modules nécessaires au transfert
(usbserial et visor) ne se chargent pas automatiquement, bien que le
système reconnaisse l'engin :
J'avais trouvé la solution mais oublié de la poster... mieux vaut tard
que jamais : le module visor était blacklisté dans un fichier de conf
sous /etc/modprobe.d ! Ligne commentée, problème disparu.
Ça peut se blacklister tout seul un module ?
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
Le 6 septembre 2018, à 11:38, Lucas Levrel a écrit :
Lorsque je connecte mon Palm, les modules nécessaires au transfert (usbserial et visor) ne se chargent pas automatiquement, bien que le système reconnaisse l'engin :
J'avais trouvé la solution mais oublié de la poster... mieux vaut tard que jamais : le module visor était blacklisté dans un fichier de conf sous /etc/modprobe.d ! Ligne commentée, problème disparu.
Ça peut se blacklister tout seul un module ? -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Lucas Levrel
Le 18 décembre 2018, à 18:42, Pierre www.aribaut.com a écrit :
Le 18/12/2018 à 17:59, Lucas Levrel a écrit :
Le 6 septembre 2018, à 11:38, Lucas Levrel a écrit :
Lorsque je connecte mon Palm, les modules nécessaires au transfert (usbserial et visor) ne se chargent pas automatiquement, bien que le système reconnaisse l'engin :
J'avais trouvé la solution mais oublié de la poster... mieux vaut tard que jamais : le module visor était blacklisté dans un fichier de conf sous /etc/modprobe.d ! Ligne commentée, problème disparu.
Ça peut se blacklister tout seul un module ?
Pas à ma connaissance... je suppose qu'un mainteneur de paquet l'a trouvé gênant, moi il me manque, chacun sa config ! -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 18 décembre 2018, à 18:42, Pierre www.aribaut.com a écrit :
Le 18/12/2018 à 17:59, Lucas Levrel a écrit :
Le 6 septembre 2018, à 11:38, Lucas Levrel a écrit :
Lorsque je connecte mon Palm, les modules nécessaires au transfert
(usbserial et visor) ne se chargent pas automatiquement, bien que le
système reconnaisse l'engin :
J'avais trouvé la solution mais oublié de la poster... mieux vaut tard que
jamais : le module visor était blacklisté dans un fichier de conf sous
/etc/modprobe.d ! Ligne commentée, problème disparu.
Ça peut se blacklister tout seul un module ?
Pas à ma connaissance... je suppose qu'un mainteneur de paquet l'a trouvé
gênant, moi il me manque, chacun sa config !
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Le 18 décembre 2018, à 18:42, Pierre www.aribaut.com a écrit :
Le 18/12/2018 à 17:59, Lucas Levrel a écrit :
Le 6 septembre 2018, à 11:38, Lucas Levrel a écrit :
Lorsque je connecte mon Palm, les modules nécessaires au transfert (usbserial et visor) ne se chargent pas automatiquement, bien que le système reconnaisse l'engin :
J'avais trouvé la solution mais oublié de la poster... mieux vaut tard que jamais : le module visor était blacklisté dans un fichier de conf sous /etc/modprobe.d ! Ligne commentée, problème disparu.
Ça peut se blacklister tout seul un module ?
Pas à ma connaissance... je suppose qu'un mainteneur de paquet l'a trouvé gênant, moi il me manque, chacun sa config ! -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Pascal Hambourg
Le 19/12/2018 à 18:02, Lucas Levrel a écrit :
Le 18 décembre 2018, à 18:42, Pierre www.aribaut.com a écrit :
Le 18/12/2018 à 17:59, Lucas Levrel a écrit :
Le 6 septembre 2018, à 11:38, Lucas Levrel a écrit :
Lorsque je connecte mon Palm, les modules nécessaires au transfert (usbserial et visor) ne se chargent pas automatiquement, bien que le système reconnaisse l'engin :
J'avais trouvé la solution mais oublié de la poster... mieux vaut tard que jamais : le module visor était blacklisté dans un fichier de conf sous /etc/modprobe.d ! Ligne commentée, problème disparu.
C'était l'explication la plus probable puisque le module visor contient bien un alias avec les identifiants USB du périphérique : modinfo visor (...) alias: usb:v0830p0061d*dc*dsc*dp*ic*isc*ip*in*
Ça peut se blacklister tout seul un module ?
Non, pas plus que ça ne peut se charger tout seul.
Pas à ma connaissance... je suppose qu'un mainteneur de paquet l'a trouvé gênant, moi il me manque, chacun sa config !
Quelle distribution ? Tu as cherché à quel paquet ce fichier appartenait ?
Le 19/12/2018 à 18:02, Lucas Levrel a écrit :
Le 18 décembre 2018, à 18:42, Pierre www.aribaut.com a écrit :
Le 18/12/2018 à 17:59, Lucas Levrel a écrit :
Le 6 septembre 2018, à 11:38, Lucas Levrel a écrit :
Lorsque je connecte mon Palm, les modules nécessaires au transfert
(usbserial et visor) ne se chargent pas automatiquement, bien que le
système reconnaisse l'engin :
J'avais trouvé la solution mais oublié de la poster... mieux vaut
tard que
jamais : le module visor était blacklisté dans un fichier de conf sous
/etc/modprobe.d ! Ligne commentée, problème disparu.
C'était l'explication la plus probable puisque le module visor contient
bien un alias avec les identifiants USB du périphérique :
Le 18 décembre 2018, à 18:42, Pierre www.aribaut.com a écrit :
Le 18/12/2018 à 17:59, Lucas Levrel a écrit :
Le 6 septembre 2018, à 11:38, Lucas Levrel a écrit :
Lorsque je connecte mon Palm, les modules nécessaires au transfert (usbserial et visor) ne se chargent pas automatiquement, bien que le système reconnaisse l'engin :
J'avais trouvé la solution mais oublié de la poster... mieux vaut tard que jamais : le module visor était blacklisté dans un fichier de conf sous /etc/modprobe.d ! Ligne commentée, problème disparu.
C'était l'explication la plus probable puisque le module visor contient bien un alias avec les identifiants USB du périphérique : modinfo visor (...) alias: usb:v0830p0061d*dc*dsc*dp*ic*isc*ip*in*
Ça peut se blacklister tout seul un module ?
Non, pas plus que ça ne peut se charger tout seul.
Pas à ma connaissance... je suppose qu'un mainteneur de paquet l'a trouvé gênant, moi il me manque, chacun sa config !
Quelle distribution ? Tu as cherché à quel paquet ce fichier appartenait ?
Lucas Levrel
Le 19 décembre 2018, à 20:26, Pascal Hambourg a écrit :
Pas à ma connaissance... je suppose qu'un mainteneur de paquet l'a trouvé gênant, moi il me manque, chacun sa config !
Quelle distribution ?
Mint 19.
Tu as cherché à quel paquet ce fichier appartenait ?
Je n'avais pas eu le temps. Le blacklist est dans /etc/modprobe.d/libpisock9.conf du paquet libpisock9. Du coup j'ai lu libpisock9/README.libusb.gz et ils expliquent le pourquoi : utiliser une méthode plus « moderne » basée sur libusb. Selon l'adage « si ça marche, ne répare pas », je décide de conserver ma bonne vieille config qui nécessite le module visor. Merci pour ton message. -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 19 décembre 2018, à 20:26, Pascal Hambourg a écrit :
Pas à ma connaissance... je suppose qu'un mainteneur de paquet l'a trouvé
gênant, moi il me manque, chacun sa config !
Quelle distribution ?
Mint 19.
Tu as cherché à quel paquet ce fichier appartenait ?
Je n'avais pas eu le temps.
Le blacklist est dans /etc/modprobe.d/libpisock9.conf du paquet
libpisock9. Du coup j'ai lu libpisock9/README.libusb.gz et ils expliquent
le pourquoi : utiliser une méthode plus « moderne » basée sur libusb.
Selon l'adage « si ça marche, ne répare pas », je décide de conserver ma
bonne vieille config qui nécessite le module visor.
Merci pour ton message.
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Le 19 décembre 2018, à 20:26, Pascal Hambourg a écrit :
Pas à ma connaissance... je suppose qu'un mainteneur de paquet l'a trouvé gênant, moi il me manque, chacun sa config !
Quelle distribution ?
Mint 19.
Tu as cherché à quel paquet ce fichier appartenait ?
Je n'avais pas eu le temps. Le blacklist est dans /etc/modprobe.d/libpisock9.conf du paquet libpisock9. Du coup j'ai lu libpisock9/README.libusb.gz et ils expliquent le pourquoi : utiliser une méthode plus « moderne » basée sur libusb. Selon l'adage « si ça marche, ne répare pas », je décide de conserver ma bonne vieille config qui nécessite le module visor. Merci pour ton message. -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Pascal Hambourg
Le 21/12/2018 à 11:33, Lucas Levrel a écrit :
Mint 19.
Tu as cherché à quel paquet ce fichier appartenait ?
Je n'avais pas eu le temps. Le blacklist est dans /etc/modprobe.d/libpisock9.conf du paquet libpisock9.
dpkg -S /etc/modprobe.d/libpisock9.conf ne prend pas beaucoup de temps.
Le 21/12/2018 à 11:33, Lucas Levrel a écrit :
Mint 19.
Tu as cherché à quel paquet ce fichier appartenait ?
Je n'avais pas eu le temps.
Le blacklist est dans /etc/modprobe.d/libpisock9.conf du paquet
libpisock9.
dpkg -S /etc/modprobe.d/libpisock9.conf
ne prend pas beaucoup de temps.
Tu as cherché à quel paquet ce fichier appartenait ?
Je n'avais pas eu le temps. Le blacklist est dans /etc/modprobe.d/libpisock9.conf du paquet libpisock9.
dpkg -S /etc/modprobe.d/libpisock9.conf ne prend pas beaucoup de temps.
Pascal Hambourg
Le 18/12/2018 à 17:59, Lucas Levrel a écrit :
le module visor était blacklisté dans un fichier de conf sous /etc/modprobe.d ! Ligne commentée, problème disparu.
Une remarque au cas où : avant de modifier un fichier appartenant à un paquet, il faut vérifier qu'il est géré en conffile avec dpkg -s <paquet> (pour une distribution basée sur Debian comme Mint) Ici, c'est bien le cas, comme souvent avec les fichiers de configuration dans /etc : Conffiles: /etc/modprobe.d/libpisock9.conf 11e33ed7adbc3dc327c87baf9cc08720 Dans ce cas, la modification pourra être conservée lors d'une mise à jour du paquet. Dans le cas contraire, elle serait écrasée par la mise à jour donc la bonne méthode consiste à mettre en place un "détournement" avec dpkg-divert. Les solutions de facilité "sales et rapides" du genre rendre le fichier modifié immmuable avec chattr +i pour empêcher le paquet de l'écraser sont à éviter.
Le 18/12/2018 à 17:59, Lucas Levrel a écrit :
le module visor était blacklisté dans un fichier de conf
sous /etc/modprobe.d ! Ligne commentée, problème disparu.
Une remarque au cas où : avant de modifier un fichier appartenant à un
paquet, il faut vérifier qu'il est géré en conffile avec
dpkg -s <paquet>
(pour une distribution basée sur Debian comme Mint)
Ici, c'est bien le cas, comme souvent avec les fichiers de configuration
dans /etc :
Dans ce cas, la modification pourra être conservée lors d'une mise à
jour du paquet. Dans le cas contraire, elle serait écrasée par la mise à
jour donc la bonne méthode consiste à mettre en place un "détournement"
avec dpkg-divert. Les solutions de facilité "sales et rapides" du genre
rendre le fichier modifié immmuable avec chattr +i pour empêcher le
paquet de l'écraser sont à éviter.
le module visor était blacklisté dans un fichier de conf sous /etc/modprobe.d ! Ligne commentée, problème disparu.
Une remarque au cas où : avant de modifier un fichier appartenant à un paquet, il faut vérifier qu'il est géré en conffile avec dpkg -s <paquet> (pour une distribution basée sur Debian comme Mint) Ici, c'est bien le cas, comme souvent avec les fichiers de configuration dans /etc : Conffiles: /etc/modprobe.d/libpisock9.conf 11e33ed7adbc3dc327c87baf9cc08720 Dans ce cas, la modification pourra être conservée lors d'une mise à jour du paquet. Dans le cas contraire, elle serait écrasée par la mise à jour donc la bonne méthode consiste à mettre en place un "détournement" avec dpkg-divert. Les solutions de facilité "sales et rapides" du genre rendre le fichier modifié immmuable avec chattr +i pour empêcher le paquet de l'écraser sont à éviter.
Lucas Levrel
Le 21 décembre 2018, à 20:58, Pascal Hambourg a écrit :
Le 18/12/2018 à 17:59, Lucas Levrel a écrit :
le module visor était blacklisté dans un fichier de conf sous /etc/modprobe.d ! Ligne commentée, problème disparu.
Une remarque au cas où : avant de modifier un fichier appartenant à un paquet, il faut vérifier qu'il est géré en conffile avec dpkg -s <paquet> (pour une distribution basée sur Debian comme Mint) Ici, c'est bien le cas, comme souvent avec les fichiers de configuration dans /etc : Conffiles: /etc/modprobe.d/libpisock9.conf 11e33ed7adbc3dc327c87baf9cc08720 Dans ce cas, la modification pourra être conservée lors d'une mise à jour du paquet. Dans le cas contraire, elle serait écrasée par la mise à jour donc la bonne méthode consiste à mettre en place un "détournement" avec dpkg-divert. Les solutions de facilité "sales et rapides" du genre rendre le fichier modifié immmuable avec chattr +i pour empêcher le paquet de l'écraser sont à éviter.
Merci pour tes conseils (celui-ci et l'autre sur dpkg -S). Je débute en Debian-like. Je n'ai notamment pas encore eu le temps de me pencher sur les différences et usages de dpkg, apt, apt-* et aptitude... -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 21 décembre 2018, à 20:58, Pascal Hambourg a écrit :
Le 18/12/2018 à 17:59, Lucas Levrel a écrit :
le module visor était blacklisté dans un fichier de conf sous
/etc/modprobe.d ! Ligne commentée, problème disparu.
Une remarque au cas où : avant de modifier un fichier appartenant à un
paquet, il faut vérifier qu'il est géré en conffile avec
dpkg -s <paquet>
(pour une distribution basée sur Debian comme Mint)
Ici, c'est bien le cas, comme souvent avec les fichiers de configuration dans
/etc :
Dans ce cas, la modification pourra être conservée lors d'une mise à jour du
paquet. Dans le cas contraire, elle serait écrasée par la mise à jour donc la
bonne méthode consiste à mettre en place un "détournement" avec dpkg-divert.
Les solutions de facilité "sales et rapides" du genre rendre le fichier
modifié immmuable avec chattr +i pour empêcher le paquet de l'écraser sont à
éviter.
Merci pour tes conseils (celui-ci et l'autre sur dpkg -S). Je débute en
Debian-like. Je n'ai notamment pas encore eu le temps de me pencher sur
les différences et usages de dpkg, apt, apt-* et aptitude...
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Le 21 décembre 2018, à 20:58, Pascal Hambourg a écrit :
Le 18/12/2018 à 17:59, Lucas Levrel a écrit :
le module visor était blacklisté dans un fichier de conf sous /etc/modprobe.d ! Ligne commentée, problème disparu.
Une remarque au cas où : avant de modifier un fichier appartenant à un paquet, il faut vérifier qu'il est géré en conffile avec dpkg -s <paquet> (pour une distribution basée sur Debian comme Mint) Ici, c'est bien le cas, comme souvent avec les fichiers de configuration dans /etc : Conffiles: /etc/modprobe.d/libpisock9.conf 11e33ed7adbc3dc327c87baf9cc08720 Dans ce cas, la modification pourra être conservée lors d'une mise à jour du paquet. Dans le cas contraire, elle serait écrasée par la mise à jour donc la bonne méthode consiste à mettre en place un "détournement" avec dpkg-divert. Les solutions de facilité "sales et rapides" du genre rendre le fichier modifié immmuable avec chattr +i pour empêcher le paquet de l'écraser sont à éviter.
Merci pour tes conseils (celui-ci et l'autre sur dpkg -S). Je débute en Debian-like. Je n'ai notamment pas encore eu le temps de me pencher sur les différences et usages de dpkg, apt, apt-* et aptitude... -- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Jo Engo
Le Wed, 02 Jan 2019 18:59:43 +0100, Lucas Levrel a écrit :
Je n'ai notamment pas encore eu le temps de me pencher sur les différences et usages de dpkg, apt, apt-* et aptitude...
alors en très gros (et très faux, donc) - dpkg c'est du bas-niveau : on manipule directement les paquets .deb dpkg ne se soucie pas de dépôts, juste de dépendances. La ligne de commande est complexe et puissante - apt est «nouveau» car il y avait un paquet apt qui existait par ailleurs (c'était du java si j'ai bonne mémoire) qui n'avait rien voir avec le système de paquet apt a vocation de remplacer apt-get et apt-file apt-get admet des commandes comme install, remove et permet facilement d'installer un paquet apt-cache permet de faire une recherche dans le cache des paquets (cache + paquets installé si je ne m'abuse apt-file permet de chercher un fichier dans le cache des paquets (commande search et synonyme find) aptitude offre un client «plein écran» (curses) : lancer aptitude sans arguments (mais avec des option comme -u, par exemple aptitude -u lance aptitude en mode curse et met à jour les dépôts sinon aptitude admet des arguments comme apt-get et apt-file comme update (mise à jour des dépôts) safe-upgrade (mise à jour du système sans suppressions de paquets) aptitude upgrade met à jour avec éventuellement des suppressions de paquets (propose les différentes solutions en CLI) non exhaustif et éventuellement faux (je n'ai pas testé les différentes options de apt-get et aptitude -- Mat matador -bop me true jam !- En Madame Malstrom t'est né Dents et morts l'âme m'a damné Majeur tempo broda tam-tam. -- Rapilly, Robert
Le Wed, 02 Jan 2019 18:59:43 +0100, Lucas Levrel a écrit :
Je n'ai notamment pas encore eu le temps de me pencher sur les
différences et usages de dpkg, apt, apt-* et aptitude...
alors en très gros (et très faux, donc)
- dpkg c'est du bas-niveau : on manipule directement les paquets .deb dpkg
ne se soucie pas de dépôts, juste de dépendances. La ligne de commande
est complexe et puissante
- apt est «nouveau» car il y avait un paquet apt qui existait par
ailleurs (c'était du java si j'ai bonne mémoire) qui n'avait rien voir
avec le système de paquet apt a vocation de remplacer apt-get et apt-file
apt-get admet des commandes comme install, remove et permet facilement
d'installer un paquet
apt-cache permet de faire une recherche dans le cache des paquets (cache
+ paquets installé si je ne m'abuse
apt-file permet de chercher un fichier dans le cache des paquets
(commande search et synonyme find)
aptitude offre un client «plein écran» (curses) : lancer aptitude sans
arguments (mais avec des option comme -u, par exemple
aptitude -u lance aptitude en mode curse et met à jour les dépôts
sinon aptitude admet des arguments comme apt-get et apt-file comme update
(mise à jour des dépôts) safe-upgrade (mise à jour du système sans
suppressions de paquets)
aptitude upgrade met à jour avec éventuellement des suppressions de
paquets (propose les différentes solutions en CLI)
non exhaustif et éventuellement faux (je n'ai pas testé les différentes
options de apt-get et aptitude
--
Mat matador -bop me true jam !-
En Madame Malstrom t'est né
Dents et morts l'âme m'a damné
Majeur tempo broda tam-tam.
-- Rapilly, Robert
Le Wed, 02 Jan 2019 18:59:43 +0100, Lucas Levrel a écrit :
Je n'ai notamment pas encore eu le temps de me pencher sur les différences et usages de dpkg, apt, apt-* et aptitude...
alors en très gros (et très faux, donc) - dpkg c'est du bas-niveau : on manipule directement les paquets .deb dpkg ne se soucie pas de dépôts, juste de dépendances. La ligne de commande est complexe et puissante - apt est «nouveau» car il y avait un paquet apt qui existait par ailleurs (c'était du java si j'ai bonne mémoire) qui n'avait rien voir avec le système de paquet apt a vocation de remplacer apt-get et apt-file apt-get admet des commandes comme install, remove et permet facilement d'installer un paquet apt-cache permet de faire une recherche dans le cache des paquets (cache + paquets installé si je ne m'abuse apt-file permet de chercher un fichier dans le cache des paquets (commande search et synonyme find) aptitude offre un client «plein écran» (curses) : lancer aptitude sans arguments (mais avec des option comme -u, par exemple aptitude -u lance aptitude en mode curse et met à jour les dépôts sinon aptitude admet des arguments comme apt-get et apt-file comme update (mise à jour des dépôts) safe-upgrade (mise à jour du système sans suppressions de paquets) aptitude upgrade met à jour avec éventuellement des suppressions de paquets (propose les différentes solutions en CLI) non exhaustif et éventuellement faux (je n'ai pas testé les différentes options de apt-get et aptitude -- Mat matador -bop me true jam !- En Madame Malstrom t'est né Dents et morts l'âme m'a damné Majeur tempo broda tam-tam. -- Rapilly, Robert