Christophe C a écritJe crois comprendre la logique utilisateur des paquets click, mais pas la démarche technique. S'il ne faut pas être root, c'est que cela ne s'installe pas vriament ? C'est de la virtualisation ? Comment on gère la sécurité avec ce système sans mot de passe ? Il y a des info disponibles, là-dessus ?
Les paquets clicks s'installent dans /opt.
Il faut aussi savoir que les .deb contiennent des scripts écrits par le mainteneur et que ceux-ci sont exécutés en root lors de l'installation/suppression. Ce qui implique donc tout une phase de relecture et de validation manuelle à chaque introduction d'un nouveau paquet ou d'une mise à jour.
Tu comprends bien qu'il est hors de question de laisser un développeur quelconque uploader un paquet .deb dans les dépôts alors que celui-ci peut très bien exécuter un
rm -rf / lors de son installation.
Les paquets Click sont des espèces de .deb idiots : pas de dépendance (chacun contient ce qui lui est nécessaire pour fonctionner, donc rien ne casse en cas de changement sur une autre appli), pas de scripts mainteneur (donc plus besoin de l'installer en root).
Couplé à un système de sandboxing (fournis par la combinaison de Unity 8/Mir/Apparmor/Upstart), on obtient un système qui permet de faire confiance à n'importe quel paquet Click sans avoir besoin de l'auditer manuellement. Ce qui fourni donc les avantages utilisateur que j'ai cité précédemment.
Techniquement les paquets Click sont aussi plus simple à créer par les développeurs. C'est de là dont vient le nom d'ailleurs : qu'il n'y ai qu'un bouton à cliquer pour packager une application.
Empaqueter en .deb est bien plus complexe, même si le format permet aussi de faire bien plus de choses (c'est bien pour ça que Click ne replacera pas les .deb pour autre chose que les applications de « haut niveau »).
