Re: [ENGLOBE-DEVEL] [POPS] Developement

[Stéphane Bauland <joligardon@xxxxxxxxx>]

Maxime BRUNEL wrote:
> Salut,
>
> Le développement de pops a été repris il y a qlques semaines déjà . Pour l'instant, il y a comme développeurs :
>
> - maxtoo
> - rookmoot
> - taka0
>   
En parlant de ça, faudrait mettre les headers de licences dans les *.c.

> Je le rappelle, notre projet est de fournir dans Englobe, un systÚme de paquets capable de gérer les logiciels sous forme direct en binaires pour l'instant.
>   
Englobe c'est pas plutot un projet de distribution ou pops est un 
sous-projet de gestion de paquet ?? ;)
> L'organisation se fait en deux temps : une librairie pour avoir un panel de fonctions pour la gestion des paquets cà d, l'installation, la recherche... et un frontend normal qui sera utilisable en console et pourquoi pas aprés un gui. Il est important qu'on suive cette organisation, tout simplement, pour qu'on puisse disposer de plusieurs gui avec la même libraire sans avoir des forks de partout.
>   
Un truc qui me parrait essentiel à mettre en avant. C'est que la libpops 
doit etre le plus généric possible,  pour lui permettre de pouvoir etre 
utiliser en plusieurs modes (console, gui, module bureau.., etc...). Se 
qui implique que l'application doit avoir un niveau d'activité important...

Pour prendre un exemple, pour installer un paquet il ne devra pas suffir 
de faire :

  pops_install_pkg("bash");

mais bien une masse de fonctions qui permettent de récupérer tel ou tel 
information et de les traiter comme bon nous semble par la suite ;)
> Notre objectif premier est de sortir une version utilisable de la librairie et d'un frontend qui soit utilisable mais trÚs simple. Donc on fais le strict minimum.
>
> | Fonctions de Pops
> --------------------
>
> - les paquets sont organisés dans un arbre avec des catégories représentant le théme des paquets. Exemple :
>   
>   arbre - category 
>         \ category2 - paquet
>                     - paquet2
>             [...]      [...]
>
>   la gestion de l'arbre a été implentée même s'il reste qlques points à voir
>
> - les paquets ont un format binaire, et codé avec eet. Nous utilisons donc, la librairie eet faisant partie d'EFL pour définir/lire les paquets. La partie eet dans pops a elle aussi été implentée.
>
> - pour ce qui est du téléchargement des paquets, nous n'utiliserons pas rsync, mais plutot une methode à la debian ou rpm. Le téléchargement se fera surement par curl.
>   
En se qui concerne le Tree dans pops, je pense qui si ont doit se 
tourner vers une gestion des downloads avec curl en utilisant l'espris 
de apt. Il faudrait repenser certaines choses. Déja la gestion d'un tree 
sans rsync n'est pas la bonne idée (pas très réaliste: Tout est maj il 
n'y a pas de diffing)

Se que je propose en remplacement est assez simple, et pas très long a 
coder. (j'en attend des feedbacks, car c'est la partie que je vais 
traiter d'ici peu).

Le repository englobe distant ressemblerait a ca :

/root
  | - Pops.eet
  | - packages/
       | - category1/
            | - binaire-stable.tar.bz2
            | - binaire-unstable.tar.bz2
            | - ...
       | - category2/
       | - ...
   | - sources/ (voir ci-dessous)

La mise a jour de pops récupererait le fichier Pops.eet qui contiendrait 
TOUT le tree courant et TOUTES les informations sur CHAQUE paquet. Ce 
fichier serait assez gros en lui meme (peut etre une gestion de diff 
pour la suite comme sous debian). Une fois ce fichier récupérer lors de 
la mise à jour, pops crérait un nouveau cache comprenant l'essentiel.

Une recherche du paquet dans le cache retournerait les infos contenu 
dans Pops.eet pour le paquet désirer. Se qui nous permettrait de 
connaitre le PATH complet vers le .tar.bz2 du binaire :    

  http://englobe/root/paquages/category1/binaire-stable.tar.bz2

Personnelement, je trouve ce schéma beaucoup plus adapté au 
fonctionnement d'un packagemanager binaire.
Et le code beaucoup plus simple a gerer vu qu'il suffit juste de 
traverser un seul fichier pour récupérer les bonnes informations.
> - le cache est un peu prés fini. Il prend en compte l'organisation de l'arbre, et pointe vers le chemin des paquets, donc ils ne sont pas inclus dans le cache. Pour l'instant, il est basique : si le fichier /usr/pops/timestamp est modifié, le cache est regeneré. Il ne reste plus qu'à ce que le cache puisse gérer plusieurs arbres.
>
> - l'installation et la désinstallation n'est pas encore codé ainsi que la gestion des dépendances.
>
> - la gestion des versions des paquets est presque finie.
>
> Bon, voila, je voulais juste presenté vite fait (j'ai du oublier des trucs) ce que pops fera/fait. Il y a des fonctions, genre la gestion des dépendances, qui vont aller trÚs vite à faire, vu que l'ancienne version de libpops savait trÚs bien géré ca.
>
> | Organisation pour le développement
> ------------------------------------
>
> Je viens de penser à quelque chose qui serait pas mal important, c'est que quand un développeur committe une fonction essentielle pour libpops, il la décrive sur la mailing-list pour qu'on puisse déjà savoir qu'elle existe, et ensuite pour améliorer son API ou même son fonctionnement.
>   
Je pense que une bout de code d'exemple en entete dans le .c est aussi 
bien qu'un long discourt sur la ml.
J'en ai mis un dans pops_download.c, le voici :

/**
* Exemple :
*
*   Pops_Download *pd = NULL;
*
*   pd = pops_download_new("http://here/is/my/file.tar.bz2";, "/home/me");
*   pops_download_progress_cb_set(pd, progress_cb);
*
*   pops_download_perform(pd);
*
*/
> Voila.
>
> Bon aprém'
>
>   
J'en ai fini pour le moment :) Si vous avez des choses a dire, ésiter 
pas... Je commence a coder le system de repository
maintenant, on en reparle...

Tcho!