Impossible de poursuivre aucune autorisation

Non ceci n'a rien à voir et en plus si tu le fais sans réfléchir, ça peut être dangereux.

Le gestionnaire de paquets apt positionne un verrou (lock) en créant un fichier vide (/var/cache/apt/archives/lock) pendant toute la période où il tourne. Ceci garantit deux choses :
- c'est bien root qui lance le gestionnaire de paquet (car seul lui pourra créer ce fichier)
- seul une instance du gestionnaire de paquets est en train de tourner (si on lance un deuxième gestionnaire de paquets, le verrou étant positionné, il ne se lancera pas).

Ainsi si tu supprimes un verrou qui était positionné à juste titre, tu risques de lancer plusieurs gestionnaires de paquets en parallèle et faire n'importe quoi. Supprimer ce verrou n'a de sens que si une instance du gestionnaire de paquet à été quitté salement. Dans ce cas, un verrou résiduel reste et certains paquets sont partiellement installé, ce qui justifie alors les commandes que tu évoques.

Maintenant, si on regarde le problème posé initialement, le problème ne se pose pas pour lancer le gestionnaire de paquet, mais pour qu'un utilisateur connecté en mode graphique puisse ouvrir une application graphique qui aura des droits root (ie une fenêtre lancée au travers de kdesudo ou gksudo). Pour cela, il faut que root autorise cette utilisateur à le faire, ce qui se fait par l'intermédiaire de la commande visudo (voir message précédent), et c'est donc un autre problème, qui se pose en amont de celui que tu évoques.

Certes, même si je connais le principe du lock, je comprends ton point de vue avec l'élévation de pouvoir. Néanmoins ce que tu donnes c'est la raison, et non la solution, du moins une solution satisfaisante. Muon se doit de demander automatiquement l'élévation de pouvoir, sans que l'utilisateur ait à demander préalablement (sinon l'application du menu de lancement, les liens apt:/ sont inutilisables.)

Comme la « solution » que j'ai reprise avait été donnée dans deux forums, j'ai supposé qu'elle marchait. Mais comme ni la mienne (mauvaise solution) ni la tienne (bonne mais inadaptée) ne correspondent au besoin, j'ai fouillé encore un peu et j'ai trouvé ceci :
http://askubuntu.com/questions/80545/ubuntu-11-10-with-kde-installed-does-not-prompt-for-elevation-for-privileged-ops
Qui m'a mené à ceci :
https://bugs.launchpad.net/ubuntu/+source/policykit-1-gnome/+bug/867737
Il s'agit d'un vrai bug, lors de l'installation de kubuntu-desktop
Installer polkit-kde-1 semble résoudre le problème, en espérant que ça n'ait pas d'effet collatéral sur les droits dans l'environnement gnome.

Pas de soucis. La solution que j'ai donné correspondait au problème initial de boting, à savoir un kdesudo (ou un gksudo) qui ne fonctionnait pas, du coup je ne comprends pas trop pourquoi tu dis qu'elle ne correspond pas.

Mais sinon effectivement comme tu l'indiques, polkit peut aussi être un élément impactant. Dans ce cas il s'agit d'un bug ou d'un système mal installé (donc avant de voir ça, autant vérifier que tout est déjà bien configuré côté sudo).

Après vu que boting n'a jamais répondu, je doute que ça vaille le coup de chercher les éléments qui peuvent le bloquer (ou qui ont pu le bloquer). Après j'imagine que si tu es arrivé sur ce fil de discussion c'est que tu cherches aussi à faire marcher muon sans succès ? Ceci dit je ne vois pas trop l'intérêt de muon, si comme boting, tu utilises kubuntu. Car kpackagekit me semble déjà faire tout le nécessaire, non ?

Personnellemen je ne l'utilise pas, mais j'ai eu un ami qui a le problème, et j'ai noté ce problème chez tous ceux qui font la migration ubuntu -> kubuntu-desktop sur oneiric (et non l'install directe)

Le problème de muon est qu'il est considéré comme gestionnaire de package par défaut dans kubuntu Oneric Ocelot, et donc tout ce qui est deb, apt:/, voir menu "installez des logiciels" est automatiquement lié à Muon :/

Donc il me semblait plus rapide/efficace de le faire fonctionner correctement que de chercher à modifier toutes les associations :p