apturl étendu pour gérer les PPAs

moths-art · Le 05/12/2013, à 13:38

Bonjour à tous.

Suite à une discussion ici, je me suis rendu compte que les ppas manquaient sans doute d'atouts en terme de facilité et de rapidité d'installation.

J'apprécie apturl car il permet de partager rapidement, via une url, l'installation d'une liste de logiciels.
Je pensais tout d'abord copier les sources et créer un équivalent pour les ppas mais en y regardant de plus près (dans le code de apturl et add-apt-repository),il s'avère qu'il lui manquait juste quelques éléments pour pouvoir remplir ce rôle.

L'idée est donc de partir sur un fork.

Voilà ce qui serait possible après ces modifs :

apt://ppa.launchpad.net/linaro-maintainers/toolchain/ubuntu?package=qemu-linaro

voir ceci pour plusieurs ppas :

apt://ppa.launchpad.net/ferramroberto/gimp,ppa.launchpad.net/linaro-maintainers/toolchain?package=qemu-linaro,gimp,gmic

Jusqu'à là : vous me diriez : quel intérêt et quels changements?
En effet, dans le premier exemple, ces paquets sont effectivement installés si et seulement si le ppa est déjà enregistré et activé.

L'objectif est donc de combler cette faille.
Le but (dans le dernier exemple) est de permettre ceci:

sudo add-apt-repository ppa:ferramroberto/gimp ppa:linaro-maintainers/toolchain
sudo apt-get update
sudo apt-get install qemu-linaro gimp gmic

Bien évidement, l'ajout de ppas n'étant pas sans risques, une fenêtre modal viendrais avertir l'utilisateur des risques qu'ils encourent,
de la liste des ppas qu'il s'apprête à installer ainsi que les paquets associés.

J'ai commencé à travailler sur ce fork mais je me demande avant d'aller plus loin :

suis-je le seul intéressé?
existe-t-il un équivalent?
il y a t-il d'autres idées d'évolutions?

Je pense procéder en 2 étapes :

mis à dispo du paquet sur github (j'suis vraiment pas à l'aise avec leur bazaar)
création d'un ppa dédié (voir création d'une branch bzr)

Le dernier point peut faire sourire : pour faciliter l'installation des ppas, il faut installer un ppa!!
L'idée étant, bien évidement d'alerter les mecs de canonical et la communauté ubuntu afin d'inclure ce travail au plus vite.
J'ai bon espoir en voyant que des projets du même acabit (ppa-purge par exemple) ont eu un accueil favorable.

moths-art · Le 13/01/2014, à 10:42

Avancement, procédures d'installation, frustrations et objectifs

Avancement

Les fêtes passés et les neurones reconnectés, je donne un retour du projet.

J'ai mis les sources sur mon compte github : https://github.com/mothsART/apturl
et j'ai créé un dépôt ppa pour l'occasion : https://launchpad.net/~jerem-ferry/+archive/apturl

Pour l'installer :

sudo add-apt-repository ppa:jerem-ferry/apturl

Avant de me lancer tête baissé dans ce projet, j'ai essayé de faire un tour d'horizon du soft et de ses limitations.
J'ai vite délaissé la doc pour lire le code directement (de add-apt-repository, synaptic par la même occasion)... mais je suis encore parfois perdu entre l'API de Debian et les ajouts de Canonical.
Il faudrait franchement un truc bien documenté quelque part.

Les tests unitaires du projet, même s'ils sont maigres m'ont permis de cibler exactement ce qu'un apturl peut faire.
La lecture du code m'a appris que mon idée était loin d'être saugrenue car une ébauche existait déjà.

Une fois le paquet installé, voici ce qu'il est possible de faire actuellement :

1. en ligne de commande :

apturl apt://launchpad.net/~mvo/ppa?package=2vcard

ou

apturl apt+http://launchpad.net/~mvo/ppa?package=2vcard

2. lien html : apt://launchpad.net/~chris-lea/redis-se … dis-server

Ce qui est bien évidement intéressant ici, c'est la possibilité d'ajouter à la volée un ppa (sudo add-apt-repository && sudo apt-get update) dans ces dépôts et d'installer un logiciel y figurant.(si le soft existe déjà sous ce nom, il sera mis à jour à la version apparenté au ppa).
Si le dépôt est inactif (commenté dans le source.list), il sera réactivé.
Une grande partie du contrat est donc résolu : simplifier l'installation d'un ppa et des softs associés! (pas de ligne de commande, juste un lien et des fenêtres de dialogues)
Mais c'est encore loin d'être parfait...

Installation

1. pré-requis (Dépendances) :

$ sudo apt-get install debhelper cdbs lintian build-essential fakeroot devscripts pbuilder dh-make debootstrap

2. Ma procédure d'empaquetage

$ mkdir apturl
$ cd apturl
$ git clone https://github.com/mothsART/apturl

$ cd apturl
$ dch -i

$ debuild -k0x7929777B -S -sa --lintian-opts -i

3. Envoi sur le serveur

$ cd ..
$ dput ppa:jerem-ferry/apturl apturl_0.6ubuntu4_source.changes

4. Tests en local

Création des paquets .deb pour des tests en local

$ sudo pbuilder build *.dsc
$ cd /var/cache/pbuilder/result
$ sudo dpkg -i apturl-common_0.6ubuntu4_amd64.deb
$ sudo dpkg -i apturl_0.6ubuntu4_amd64.deb

Frustration

* Le code était vraiment pas PEP8 (norme python) : j'ai commencé à uniformiser tout ça!
* ça ne fonctionne que sous GTK.
Vu que mes objectifs sont encore nombreux, pas encore assez net et que je manque cruellement de temps, je préfère me consacrer sur la partie GTK qui devrait correspondre à une majorité.
Une fois que ça sera plus stable, je me pencherais sur QT.

* Au départ, je pensais réutiliser juste le code nécessaire de "add-apt-repository" pour l'installation mais, je préfère, par vigilance, utiliser le module subprocess au cas ou l'API venait à changer dans les versions futures d'Ubuntu.
C'est pas forcément la manière la plus propre mais je m'en contente pour l'instant.

* Pas mal d'incohérences dans la GUI (ergonomie à la windows xp):
* si l'on clique sur un lien apt avec 6 paquets à installer et que 4 de ceux ci sont déjà installé, on se tape 4 fenêtres modales les une derrières les autres... c'est vraiment d'un mauvais gout.
* l'ajout d'un ppa était au départ transparent : pas de belle fenêtre pour dire qu'on a ajouté tel ppa et pas non plus de fenêtre de rechargement de paquet (apt-get update)... c'est assez frustrant donc prioritaire.
* un 'apt-get install' ne force pas la dernière version. (un ppa fournissant une version supérieur d'un logiciel déjà existant dans les dépôts officiels et déjà installé)

* J'ai passé bcp de temps sur l'empaquetage. C'est encore ma bête noir et suis sans doute à la ramasse.(même si j'ai pas mal appris sur le sujet)
Si il y a des critiques, suggestions la dessus, j'en serais infiniment reconnaissant.

* launchpad : l'ajout avec dput est rapide mais la création des .deb sur le serveur est longue (ça peut prendre 10 bonnes minutes)
Pb : pas de barre de progression pour donner un état de l'avancement... résultat, on fait des F5 frénétiquement.
Autre soucis : impossible de remplacer un paquet... (un dput -f ne donne rien)
il faut lui réattribuer un nom d'ou mon apturl_0.6ubuntu4 et non apturl_0.6ubuntu1!

Objectifs pour une prochaine version

* uniformiser l'interface graphique et minimiser au maximum les fenêtres popups (en me concentrant sur GTK)
* création d'une doc pour le dev et/ou le packager
* j'aimerais créer des scénarios de tests sous gtk pour valider les avancements et éviter les régressions.
Vu les possibilités, ça ne me semble pas du luxe.
Si quelqu'un a déjà fait ça... j'suis bien évidement preneur de bons conseils.
* lister les évolutions possibles et les mettre éventuellement dans une roadmap.

moths-art · Le 10/02/2014, à 18:16

Rapide news : dût à certaines limitations/incompréhension de l'API Ubuntu/launchpad, j'ai décidé de contacter Michael Vogt afin de lui poser un certain nombre de questions : état du projet, évolution des APIs etc.

Une fois que j'aurais les réponses (ou non) adéquates, je vous donnerais un retour sur l'avancement.

stay tuned.

moths-art · Le 24/02/2014, à 09:00

Michael Vogt c'est finalement décidé à me répondre.
En réalité, l'idée avait déjà été abordé depuis un moment en interne et du code inclus à cet effet dans "apturl".

Cependant, ce code partiellement créé à été désactivé (je m'en suis reservi) pour plusieurs raisons : éviter les malwares et autres softs malicieux, les softs mal codés etc.

Du coup, Michael salut mon initiative mais est hésisant (je pense qu'il est plus qu'hésitant mais il a mis les formes) quant à l'inclusion de mon code pour les risques pré-cités.

Ce qu'il manque d'après lui est une "évaluation par les pairs" (peer review) sur les PPA.
Dans ce cas précis, un apturl "amélioré" aurait sa place...
Du coup, on pourrait avoir, selon l'évaluation du ppa (négative ou positive), un message d'alerte ou non.

Maintenant, il ne m'a pas précisé si le peer review était une fonctionnalité attendu de Launchpad.
Je vais tenter d'en savoir plus à ce niveau... car maintenir un fork qui ne sera jamais inclus ne me semble pas judicieux.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 05/12/2013, à 13:38

apturl étendu pour gérer les PPAs

#2 Le 13/01/2014, à 10:42

Re : apturl étendu pour gérer les PPAs

#3 Le 10/02/2014, à 18:16

Re : apturl étendu pour gérer les PPAs

#4 Le 24/02/2014, à 09:00

Re : apturl étendu pour gérer les PPAs

Pied de page des forums