# [CONTRIB] layman pour paludis

## Bapt

J'ai fait un layman pour paludis.

Pour le moment pas encore d'ebuild. C'est codé en C et téléchargeable ici : http://baptux.free.fr/repomgr-0.1.1.tar.bz2

Nécessite dev-libs/libxml.

Le principe est d'utiliser une fichier /etc/paludis/sample.conf dans lequel on retrouve toutes les configurations par défaut que vous voulez appliquer à une conf d'overlay. repomgr en fournit un qu'il faut modifier selon ses besoins.

Pour le reste : make, make install pour la compilation/installation

make clean/uninstall pour le reste (nettoyage désinstallation);

Si vous avez une idée de nom autre que repomgr, je suis preneur.

Merci truc pour les remarques sur le codes, la version 0.1.1 corrige la "désallocation" de mémoire. et utilise snprintf.

Bon test, n'hésitez pas à me faire des retours, demande de modifications,etc.

Licence : BSD 3 clauses

----------

## truc

re, désoler de faire mon chieur, mais bon  :Smile: 

tu serais sur irc, ça serait plus simple, mais bon, ça me dit que y'as pas de bapt là :/ 

bon, je n'avais effectivement pas vu ton return dans ta boucle..., toute fois, pour éviter la duplication du code, tu devrais faire un break, et si possible concentrer le plus possible les free &Cie au même endroit, sinon,c'est vite le bordel pour s"y retrouver. et pour la valeur de retour, c'est simple, tu teste ton compteur à la sortie de la boucle, et s'il est égal au nombre d'élément, dans quel cas, ça veut dire que l'overlay n'a pas été trouvé, sinon, c'est le success  :Wink: 

Bon y'a toujours un peu de mémoire qui s'est perdue de ci de là  :Wink:  et.. tu ne testes toujours pas le retour de malloc, et si malloc échoue, ton programme il va pas être content du tout... :/

----------

## Bapt

Je viens de rajouter les tests des malloc (je ne sais pas si c'est la meilleure manière de faire ?).

J'ai rajouter les break, et mis les free à la fin de chaques fonctions. Ce n'est pas encore complètement ça, mais si j'en rajoute j'ai des sergfault, de la même manière, je teste chaque fois si la variable est null avant le free ou le xmlFree car si elle est nulle j'obtiens un segfault. (comme je le disais, je suis vraiment débutant en C  :Smile: .)

Quoi qu'il en soit, voici la version 0.1.2 avec quelques autres corrections au niveaux du code. Il reste encore des problèmes de mémoires selon valgrind. Le programme fonctionne, mais avant de rajouter des fonctionnalités, j'aimerai que le programme devienne vraiment propre au niveau mémoire.

Ensuite je voudrais lui rajouter un fichier de configuration dans lequel on pourra mettre plusieurs sources de fichiers qui seront concaténés en un fichier dans le cache. Mais c'est pour un second temps.

http://baptux.free.fr/repomgr-0.1.2.tar.bz2

----------

## titoucha

C'était pour signaler une grave erreur de programmation, quant tu fais un repomgr --help voilà une des ligne -l: list availables overlats  :Laughing: 

Autre remarque, serait-il possible que les dépôts soient triés lorsque tu fais un repomgr -l, se serait plus facile à lire.

----------

## Bapt

 *titoucha wrote:*   

> Autre remarque, serait-il possible que les dépôts soient triés lorsque tu fais un repomgr -l, se serait plus facile à lire.

 

Je vais regarder comment je peux faire...

C'est quand même là que l'on voir que perl ou autres langages c'est vachement plus haut niveau que le C  :Smile: 

----------

## kwenspc

 *Bapt wrote:*   

>  *titoucha wrote:*   Autre remarque, serait-il possible que les dépôts soient triés lorsque tu fais un repomgr -l, se serait plus facile à lire. 
> 
> Je vais regarder comment je peux faire...
> 
> C'est quand même là que l'on voir que perl ou autres langages c'est vachement plus haut niveau que le C 

 

ouais fin trier une liste en C c'est pas grand chose non plus (allez: 2lignes?! tout au plus)  :Wink: 

----------

## Bapt

 *kwenspc wrote:*   

> ouais fin trier une liste en C c'est pas grand chose non plus (allez: 2lignes?! tout au plus) 

 

Bah je l'ai dit, je suis débutant de chez débutant  :Smile: 

----------

## kwenspc

 *Bapt wrote:*   

>  *kwenspc wrote:*   ouais fin trier une liste en C c'est pas grand chose non plus (allez: 2lignes?! tout au plus)  
> 
> Bah je l'ai dit, je suis débutant de chez débutant 

 

c'est la meilleur manière d'apprendre!  :Smile: 

C'est une très bonne idée de transposer layman à paludis en tout cas

----------

## Bapt

Voila j'ai ajouté le tri et corriger la faute du -h

http://baptux.free.fr/repomgr-0.1.3.tar.bz2

par contre le tri ça fait 5 lignes ...

EDIT: pour valgrind, les fuites de mémoires lors d'un repomgr -l viennent de libxml2 donc je n'y peux rien  :Smile:  si je comprends bien ça :

```
==26326== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)

==26326== malloc/free: in use at exit: 15,098 bytes in 127 blocks.

==26326== malloc/free: 2,885 allocs, 2,758 frees, 249,654 bytes allocated.

==26326== For counts of detected errors, rerun with: -v

==26326== searching for pointers to 127 not-freed blocks.

==26326== checked 141,496 bytes.

==26326==

==26326==

==26326== 12,644 (24 direct, 12,620 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 11

==26326==    at 0x4905AFB: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)

==26326==    by 0x4A75FD0: xmlHashCreate (in /usr/lib64/libxml2.so.2.6.27)

==26326==    by 0x4AA7231: xmlXPathNewContext (in /usr/lib64/libxml2.so.2.6.27)

==26326==    by 0x401A03: get_node_set (repomgr.c:243)

==26326==    by 0x401C43: main (repomgr.c:294)

==26326==

==26326==

==26326== 640 bytes in 1 blocks are definitely lost in loss record 9 of 11

==26326==    at 0x4905BD2: realloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)

==26326==    by 0x4A97CDF: xmlXPathNodeSetAddUnique (in /usr/lib64/libxml2.so.2.6.27)

==26326==    by 0x4A9A288: (within /usr/lib64/libxml2.so.2.6.27)

==26326==    by 0x4AA4B3A: (within /usr/lib64/libxml2.so.2.6.27)

==26326==    by 0x4AA87F3: xmlXPathEvalExpression (in /usr/lib64/libxml2.so.2.6.27)

==26326==    by 0x401A14: get_node_set (repomgr.c:244)

==26326==    by 0x401C43: main (repomgr.c:294)

==26326==

==26326==

==26326== 848 bytes in 74 blocks are definitely lost in loss record 10 of 11

==26326==    at 0x4905AFB: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)

==26326==    by 0x4ABC81E: xmlStrndup (in /usr/lib64/libxml2.so.2.6.27)

==26326==    by 0x400EB0: list_overlays (repomgr.c:70)

==26326==    by 0x401C54: main (repomgr.c:295)

```

----------

## Bapt

voila un ebuild :

```

# Copyright 1999-2006 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $

inherit toolchain-funcs eutils

DESCRIPTION="layman for paludis written in C"

HOMEPAGE="http://www.gentoo.org/"

SRC_URI="http://baptux.free.fr/repomgr-${PV}.tar.bz2"

LICENSE="BSD"

SLOT="0"

KEYWORDS="~amd64 ~x86"

RESTRICT="primaryuri test"

DEPEND="dev-libs/libxml2"

src_compile() {

    emake || die

}

src_install() {

    dobin repomgr || die "dobin failed"

    dodir /etc/paludis || die "dodir"

    insopts -m0644

    insinto /etc/paludis

    doins sample.conf || die "doins failed"

}

```

----------

## titoucha

As-tu continué le développement de ton programme ?

----------

## Bapt

Oui, c'est toujours en développement, mais je n'ai vraiment pas eu beaucoup de temps ces derniers temps, de plus, j'essaye de faire ça propre, et j'ai des segmentation fault tout le temps dans la version de développement.

Ce qui arrive pour le moment, c'est : prise en compte de repository_default.conf, et un fichier de conf avec de multiples sources pour layman. 

Voila. Je reposte dès que c'est OK.

PS: @truc, j'ai bien pris en compte tes modifs/conseils, merci beaucoup  :Smile: 

----------

## truc

tu ne le fait pas en C++ finalement comme ciaran te l'avait conseillé?

En tout cas, vivement que ça soit utilisable  :Smile: 

Fais nous part, si tu le peux/veux, des tes avancements  :Smile: 

----------

## CryoGen

Bon vu que de plus en plus de monde fait quelque chose pour paludis, il serait peut-etre temps qu' à mon tour je fasse quelque chose   :Rolling Eyes: 

Malheureusement avec mon boulot ca va pas être simple mais j'ai bien envie d'adapter eix :p , j'ai déja un peu matté les sources.  L'idéal serait qu'il puisse fonctionner comme pour emerge et ainsi reduire le hook update-eix.bash à ca plus simple expression  :Smile: 

Voila l'idée qui me trotte dans la tête depuis un moment. Mais je garanti rien  :Sad: 

----------

## Bapt

 *truc wrote:*   

> tu ne le fait pas en C++ finalement comme ciaran te l'avait conseillé?

 

Non je ne le refait pas en C++ car finalement l'intérêt est minime : récupérer sur de paludis l'environnement par défaut : /etc/paludis à par ça rien... 

Je pense qu'un bon fichier de conf est mieux pour faire ça  :Smile:  Et puis je l'ai commencé en C pour apprendre le C, je n'ai pas particulièrement envie de me mettre au C++ donc voila  :Smile: 

EDIT : PS : Si quelque connait une bonne lib C pour parser les fichiers de conf (bien documentée ou avec des exemples founis avec  :Smile: ), sinon je continuerai à la faire à la main.

----------

## truc

 *CryoGen wrote:*   

> Malheureusement avec mon boulot ca va pas être simple mais j'ai bien envie d'adapter eix :p , j'ai déja un peu matté les sources.  L'idéal serait qu'il puisse fonctionner comme pour emerge et ainsi reduire le hook update-eix.bash à ca plus simple expression 
> 
> 

 

Ahah, ça serait sympa ça, j'ai vite fait décompressé les sources aussi, pour jeter un oeil, mais finalement je ne me suis pas mis dedans  :Smile: , avant, de rentrer dans les modifications profondes, tu pourrais regarder déjà pour le support des versions scm,cvs &Cie, c'est ce qui me manque le plus en ce moment.  :Smile: 

Un post sur le forum anglophone, laisse également penser qu'eix pourrait/devrait supporter les fichiers de /etc/paludis/keywords.conf, packages_mask.conf et l'autre  :Question: 

Sinon, dans la rubrique news, j'ai cru comprendre que ciaranm bossait sur un outil pour faire les recherches, j'suis incapable de me souvenir du nom, c'était un peu bizarre, quo_blabla_to (EDIT: inquisitio!!), nan, je sais plus.. en tout cas ça ne sera pas pixie  :Wink: 

Sinon, @Bapt, je ne connais pas de lib pour parser les fichiers, mais, la technique utilisée dans portage-utils, est à mon avis très souple, tu pourrais y jeter un oeil, enfin, de préférence regardes dans les sources avec les patchs comme ça tu auras directement le traitement des fichiers de conf de paludis  :Smile:  (dans main.c dans les fonctions initialize_portage_env et void initialize_overlays )

----------

## Bapt

Un pro du valgrind dans les parages ?

car en essayant de rajouter le maximum de free, je me retrouve un peu perdu. Je me demande si la libxml2 n'est pas un peu foireuse question mémoire : 

avec un petit bout de code comme ça : 

```

#include <stdio.h>

#include <stdlib.h>

#include <libxml/parser.h>

#include <libxml/xpath.h>

int main(void){

  xmlDocPtr doc = xmlParseFile("/var/cache/overlays.xml");

  xmlFreeDoc(doc);

  return 0;

}

```

Compilé comme ça : 

```
gcc -g -Wall test.c -o test `xml2-config --cflags` `xml2-config --libs`
```

et exécuter comme ça :

```
valgrind -v --leak-check=full --show-reachable=yes ./test
```

J'obtiens ça : 

```
==16987== LEAK SUMMARY:

==16987==    definitely lost: 0 bytes in 0 blocks.

==16987==      possibly lost: 0 bytes in 0 blocks.

==16987==    still reachable: 966 bytes in 20 blocks.

==16987==         suppressed: 0 bytes in 0 blocks.

```

ça a pas l'air terrible si ?

----------

## truc

bah, tu peux surement t'aider de la doc fournie avec libxml, voila ce que j'ai trouvé en gros, (j'pense pas que tu aies changer la location de la "doc" donc le lien devrait marcher ( :Smile:  ) 

Ici on parle de faire un peu de nettoyage après avoir parser un fichier, tu peux d'ailleurs voir dans l'exemple ici comme c'est mis en place.

Sinon, en me baladant la dedans, j'ai trouvé quelque chose qui devrait t'interesser: Module nanohttp from libxml2: minimal HTTP implementation allowing to fetch resources like external subset. Bon, je ne sais pas ce que c'est un "external subset" mais comme tu as l'air de maitriser xml, tu sauras surement  :Smile:  , en fait je pensais qu'il serait peut-être possible d'utiliser ça au lieu de faire appel à wget  :Question: 

Sinon, on ne peux pas faire n'importe quoi avec les pointeurs, rajouter des "free" à tout va, n'est pas la solution, il faut liberer ce qui a été réservé, pas plus pas moins :S , découvrir les pointeurs en programmant tout de suite avec une bibliothèque qu'on ne connait pas trop, n'est certainement pas la chose la plus facile à faire! Soit!, les progrès ne devraient en être que plus rapides   :Very Happy: 

Bon courage en tout cas.

Je n'ai pas essayé le xmlCleanupParser() pour voir si on avait toujours de la mémoire "reachable" après... disons, que je n'ai pas pris le temps :/, mais je serai ravi de le savoir:)

EDIT: ah bah non en fait firefox n'aime pas les lien du type file:/// :/ bon bah zut, tu voies l'idée quoi  :Razz: 

----------

## Bapt

Ca marche merci  :Smile: 

Tous les malloc/free sont libérés correctement selon valgrind  :Smile:  Merci beaucoup.

Encore un peu de nettoyage de code pour évoter la duplication de code et je fais une release, deux ou trois jours pense  :Smile: 

----------

## titoucha

En voilà une bonne nouvelle   :Very Happy: 

----------

## Bapt

Pour le impatients : la version 0.2.0pre1 est disponible : http://baptux.free.fr/repomgr-0.2.0pre1.tar.bz2

Nouveautés : 

- plus besoin de wget

- support de multiples sources layman

- fichier de configuration.

- suppression des boucles pour la recherche d'un overlay, une seul requête XPATH permet de tout faire.

Bugs connus : sur l'overlay openoffice-geki (repomgr -i openoffice-geki) problèmes de mémoire non encore déterminer.

Normalement il n'y a plus de problème de mémoires.

Le fichier de configuration est /etc/repomgr.xml (j'ai choisi le xml car repomgr utilise déjà libxml2 alors pourquoi pas continuer.

repomgr considère maintenant que l'on utilise repository_default.conf donc il ne rensigne plus rien d'autres que location et sync.

Si toute fois vous voulez rajouter des choses le fichiers de configuration de prévoit : (voir exemple fourni 'names_cache')

chaque entrée 

```

<repomgr>

  <config>

     <option name="tata" value="toto" />

  </config>

</repomgr>

```

Ajoutera un ligne tata = toto dans le fichier de configuration généré.

La ligne baselocation est la location (baselocation/overlay) où l'on souhaite créer le répertoire de destination de l'overlay.

enfin pour rajouter des overlays : 

```

<repomgr>

  <overlays>

     <overlay src="http:/..." name="..." />

  </overlays>

</repomgr>

```

Attention pour le moment seul le http est supporté pour le téléchargement des fichier layman.

Prévu pour la version 0.2.0 : 

- un argument --add-source nom http://... :Pour ajouter les nouvelles sources

- un argument --list-source : pour lister les sources déjà installées

- un argument --del-source nom : pour supprimer une source. 

- un argument --base-location chemin: pour modifier le répertoire de base

- un argument --add-option name value: pour rajouter des lignes au fichier de conf

- un argument --del-option name: pour en supprimer.

- un argument --list-option: pour lister les options

- un argument --show-base-location: pour afficher le répertoire de base.

En gros, tout pour ne jamais mettre les mains dans le fichier repomgr.xml

est prévu aussi:

- la validation des fichier layman téléchargés, 

- la validation du fichier de cache /var/cache/overlays.xml

- la validation du fichier de conf /etc/repomgr.xml

- Tests de partout sur le retour des fonctions.

PS: Il y a encore beaucoup trop de chose non testées qu'il faut tester, donc beaucoup de bugs potentiels. Je vais aussi revoir le système pour parser les arguments (des idées ?)

PS2: Au fait, il fonctionne quand même tel quel, et est utilisable, en tout cas chez moi  :Smile:  n'hésitez pas à me faire des retours.

EDIT: Vous préférez les options à la eselect ou classique ?

cad : à la eselect : 

repomgr list

repomgr add overlay ...

repomgr add option ...

repomgr show ...

repomgr del ...

classique : fonctionnement actuel

----------

## CryoGen

 *Bapt wrote:*   

> 
> 
> PS: Il y a encore beaucoup trop de chose non testées qu'il faut tester, donc beaucoup de bugs potentiels. Je vais aussi revoir le système pour parser les arguments (des idées ?)
> 
> 

 

man 3 getopt ?

----------

