Allez, c'est l'heure d'y répondre avant les vacances 😉
obrowny a écrit
Les packages click permettent d'isoler les applis entre elles.
C'est une partie de ce que permet les paquets click. En fait, plus exactement, elle restreigne ce que l'on peut faire avec dpkg, comme les conffiles, maintainers scripts, etc. En gros, tous les fichiers sont dans un dossier (nommé d'après le nom et le numéro de version de l'application). Aucun script ne tourne à l'installation. Ça permet donc:
- de s'assurer que rien de dangereux ne tourne à l'installation (contrairement aux paquets .debs, qui ont des scripts qui tournent en tant que root… À méditer lorsque que vous ajoutez $random_ppa 😉)
- de permettre l'installation de plusieurs versions du logiciel en parallèle. Sur Touch, on peut avoir l'utilisateur 1 qui fait tourner la version N, et l'utilisateur 2, qui est sur la version N+1. Un utilisateur cependant ne peut voir qu'une seule version d'une application à la fois (mais il peut revenir en arrière).
- puisque tout est dans des chemins prédictibles et uniquement dedans ceci, on y ajoute un profil apparmor, qui lui, isole les applications entre elles.
obrowny a écrit
Les packages click viennent avec leurs dépendances ce qui permet de monter en version de logiciel avec un même OS.
Est ce exact ?
Pourra donc il y avoir 10 fois une même dépendance installée pour 10 logiciels différents ou les dépendances sont elles partagées ?
Les applis installées via click prendront elles donc beaucoup plus d'espace disque que via deb ?
Oui et non. Les paquets click ajoutent leurs dependances qui ne sont pas installés par défaut. En gros, un paquet dit "je dépends des frameworks X, Y et Z" (et donc utilise ces librairies, comme Qt, etc. Tous ces éléments sont partagés et il n'y a qu'une seule installation (comme les librairies aujourd'hui)). Tout ce qui n'est pas dans ces frameworks (ou fait partie de frameworks non disponible sur cette installation) doivent par contre faire partie du paquet click.
Ce n'est pas très différent de ce qui peut déjà exister avec Firefox, Chrome, etc. en fait (ils viennent avec leur propres versions des dépendances, même si parfois ils sont disponibles dans le framework). Différentes raisons comme la stabilité, la maitrise de l'environnement, etc. Le fait de créer des vrais frameworks avec des versions de librairies clairement identifiées devraient aider justement à limiter ceci justement (en plus des mises à jours de sécurité).
Comme indiqué dans un autre message, les paquets clicks peuvent contenir des binaires de plusieurs architectures directement. J'avoue ne pas savoir pourquoi ils ne sont pas séparés comme pour les .deb traditionnels. Par contre, un download en diff binaire devrait enfin être disponible.
obrowny a écrit
La coexistence entre deb et click se fera t'elle via la même logithèque qui proposera soit le deb soit le click d'une même appli ? (quand les deux existent)
Si un deb ne propose que les màj de sécurité, le click proposera t'il systématiquement la montée en version ?
Les mises à jour d'applis seront elles toujours centralisées ou chaque appli viendra demander sa màj ?
Ubuntu Touch permettra à terme d'avoir deux environnements: l'environnement traditionnel (un chroot), où les applications ne seront pas sécurisés, etc. et un environnement click, qui correspond à l'Ubuntu Touch actuel. J'imagine qu'un grand travail de fond sera planifié pour transformer les applications en paquets click. On aura sûrement donc qu'une seule version disponible (click ou deb). Le scope click devrait permettre de gérer l'installation des .deb.
Pour info, click n'est pas très déjà des .deb. click est dpkg en fait, avec des restrictions destinées aux applications supplémentaires 🙂
obrowny a écrit
Les mises à jour d'applis seront elles toujours centralisées ou chaque appli viendra demander sa màj ?
Toujours centralisés par le store (donc pas au lancement de l'application), par contre, on pourra facilement mettre à jour qu'une seule application, un peu à la google play store. À savoir, comme je le disais, que si un utilisateur met à jour une application, un autre utilisateur du même système aura toujours la version précédente disponible, jusqu'à ce qu'il décide de mettre à jour. (et non, on n'a pas deux fois la même version installée, l'astuce est juste un jeu de liens symboliques 😉).
obrowny a écrit
Aura t'on deux systèmes de màj dont un du système et l'autre des applis ?
Oui, le système devant être au final en lecture seul, et se fera au démarrage (comme tout vrai système de mise à jour responsable pour maîtriser l'environnement, je suis heureux d'en expliquer plus au retour de vacances si besoin est vu que je pense que certains seront surpris que je dise cela 🙂).
