Some uses of apt do not install new packages which makes it less suitable for KDE neon.
Je pense qu'on parle de "apt upgrade" versus "apt full-upgrade" et c'est ce qu'on peut trouver sur internet ?
Dans ce cas, apt full-upgrade est ok aussi je suppose.
Sinon, PackageKit c'est une abstraction des différents gestionnaires de paquets, pour pouvoir fournir aux outils graphiques / en lignes de commandes une interface unifiée pour gérer les logiciels. Ça a l'air d'abstraire aussi certaines situations problématiques, comme vouloir faire une opération quand il y en a déjà une en cours : PackageKit sait mettre les opérations en file d'attente. C'est ce qu'utilisent maintenant les gestionnaires de mise à jour des distributions, ou leurs logithèques spécifiques. À charge de la distribution de fournir des méta données correctes pour PackageKit.
En soit ce n'est pas "mieux" d'utiliser pkcon que les gestionnaires de paquets eux-mêmes. Je ne crois pas qu'il y ait un intérêt particulier à utiliser pkcon, surtout si tu sais déjà utiliser le gestionnaire de paquet de la distribution : ça fait une couche d'abstraction de moins à déboguer en cas de problème.
Bref, pour moi, pkcon a surtout un intérêt potentiel pour moi, développeur d'un script ou d'une application qui ne veut pas prendre en charge tous les gestionnaires de paquets de la planète.
Après, pkcon va peut-être devenir plus agréable à utiliser avec le temps (je n'ai pas essayé). Avec cette gestion de file d'attente, ça pourrait être cool, et ça permettrait moins de blocages avec les outils graphiques s'interfaçant déjà avec PackageKit et ça pourrait permettre de se payer des erreurs du style "oh, je n'ai pas réussi à récupérer les mises à jour parce que le gestionnaire de paquet est déjà occupé".
# " Some uses of apt do not install new packages"
Posté par raphj (site web personnel) . En réponse au journal pkcon riz. Évalué à 7.
Sur ton lien, je lis:
Je pense qu'on parle de "apt upgrade" versus "apt full-upgrade" et c'est ce qu'on peut trouver sur internet ?
Dans ce cas, apt full-upgrade est ok aussi je suppose.
Sinon, PackageKit c'est une abstraction des différents gestionnaires de paquets, pour pouvoir fournir aux outils graphiques / en lignes de commandes une interface unifiée pour gérer les logiciels. Ça a l'air d'abstraire aussi certaines situations problématiques, comme vouloir faire une opération quand il y en a déjà une en cours : PackageKit sait mettre les opérations en file d'attente. C'est ce qu'utilisent maintenant les gestionnaires de mise à jour des distributions, ou leurs logithèques spécifiques. À charge de la distribution de fournir des méta données correctes pour PackageKit.
En soit ce n'est pas "mieux" d'utiliser pkcon que les gestionnaires de paquets eux-mêmes. Je ne crois pas qu'il y ait un intérêt particulier à utiliser pkcon, surtout si tu sais déjà utiliser le gestionnaire de paquet de la distribution : ça fait une couche d'abstraction de moins à déboguer en cas de problème.
Bref, pour moi, pkcon a surtout un intérêt potentiel pour moi, développeur d'un script ou d'une application qui ne veut pas prendre en charge tous les gestionnaires de paquets de la planète.
Après,
pkconva peut-être devenir plus agréable à utiliser avec le temps (je n'ai pas essayé). Avec cette gestion de file d'attente, ça pourrait être cool, et ça permettrait moins de blocages avec les outils graphiques s'interfaçant déjà avec PackageKit et ça pourrait permettre de se payer des erreurs du style "oh, je n'ai pas réussi à récupérer les mises à jour parce que le gestionnaire de paquet est déjà occupé".