# [ebuild] VBA Express 1.2

## PabOu

Bonjour !

Voilà, je suis un utilisateur de VBA Express, et son créateur (Asher256) propose deux ebuilds (vbaexpress-1.2.ebuild et une dépendance qui ne se trouve pas dans portage : FLU) avec la documentation nécessaire pour l'installer sous gentoo.

La version précédente (voir ce thread) avait été proposée sur bugzilla mais il n'y a pas de suivi depuis un bon moment (ben oui, les nouveaux ebuilds...).

Aujourd'hui, avec mes nouvelles connaissances, je me rends compte que la syntaxe de cet ebuild n'est peut-être pas la meilleure qui soit. pourquoi reprendre le flag X alors qu'il n'est pas utilisé dans l'ebuild. Peut-être que l'utilisation de ce flag ajoute automatiquement des dépendances pour Xorg ? Quoiqu'il en soit, celà ne me parait pas correct.

l'utilisation du flag gnome afin de crééer les entrées dans le menu.. et pour les autres desktop qui sont compatibles avec cette norme (dont j'ai oublie le nom) ? n'y a-t-il pas un flag qui porte un meilleur nom ?

L'utilisation de nomirror. J'ai cru comprendre que cette option était utilisée seulement pour des fichiers que gentoo ne peut pas hoster pour une raison légale (dont les licences ne permettent pas de crééer des miroirs par exemple, hors ici, c'est sous licence GPL-2)

Les liens directs vers les ebuilds :

vbaexpress-1.2.ebuild

FLU-2.14.ebuild

----------

## UB|K

salut, juste quelques remarques:

- effectivement, le flag X ne sert à rien car il le fait qu'il soit activé ou non n'a absolument aucun effet sur l'ebuild: pas de dépendances, pas d'option passée via le script configure.

- le flag gnome pour l'entrée dans le menu me semble aussi pas très judicieux: les autres utilisateurs n'auront pas de .desktop?? En théorie, grâce à une norme fdo, ces fichiers devraient être compatibles d'un environnement à un autre alors on peut soit installer par défaut le fichier .desktop contenu dans l'archive du programme soit en créer un avec la fonction dodesktop (contenu d'ans l'eclass eutils il me semble). Donc par rapport à ta question: pas besoin de flag gnome à mon avis...

- l'option "nomirror" convient très bien aux ebuild persos car il empêche portage d'aller chercher l'archive sur les mirroir gentoo (où elle n'est pas) et de passer directement à la SRC_URI de l'ebuild donc s'est pas plus mal.

- les dépendances des deux ebuilds sont pas très claires: ça serait mieux en respectant la synthaxe:

```
catégorie/paquet
```

avec éventuellement des numéros de version et un opérateur >=. Pour ça, le mieux c'est de ragarder les dépendances données sur le site, dans le README ou dans le configure (bon, là y a aucune infos, donc c'est pas gagné)

- dernière petite remarque sur la "maintenance" de l'ebuild: si une nouvelle version sort, il faut changer le nom de l'ebuild et l'editer pour changer les version dans l'ebuild. Alors qu'avec une pauvre manip c'est plus simple:

```
SRC_URI="http://vbaexpress.tuxfamily.org/${P}.tar.gz"

ou pour FLU:

SRC_URI="http://www.osc.edu/~jbryan/FLU/${PN}_${PV}.tar.gz"
```

bon, c'est tout bête mais c'est mieux comme ça!

----------

## bibi.skuk

il me semble de plus que pour vbaexpress, 

```

src_unpack()

{

   unpack ${A}

}

```

est tout a fait superflu... vu qu'il fait la même chose que la fonction par defaut

----------

## UB|K

exact, tout comme:

```
inherit eutils
```

dans l'ebuild de FLU car l'ebuild ne fait pas appel à des fonction de l'eclass eutils.

----------

## PabOu

voilà les dernieres versions, testées, elles fonctionnent :

games-emulation/vbaexpress-1.2.ebuild

x11-libs/FLU-2.14

J'ai également modifié la variable S dans l'ebuild de FLU, pour la même raison que les numeros de versions.

J'ai encore une question :

pour FLU, dans ses DEPEND, ne devrait-on pas utiliser 

```
opengl? ( virtual/opengl )
```

 ?

(je crois que ca veut dire d'avoir virtual/opengl si on utilise le flag opengl, mais j'ai besoin d'une confirmation)

----------

## UB|K

 *PabOu wrote:*   

> pour FLU, dans ses DEPEND, ne devrait-on pas utiliser 
> 
> ```
> opengl? ( virtual/opengl )
> ```
> ...

 

oui, ça serait tout à fait logique!

dans l'ebuid de vbaexpress, pourquoi as-tu mis cette ligne:

```
SRC_DIR=${WORKDIR}/${P}
```

? elle ne sert à rien car c'est exactement la définition par défaut de ${S}

deux autres trucs:

- si ton RDEPEND est vide, tu peux le virer (ok je pinaille)

- la dépendance sur media-libs/libsdl est inutile car games-emulation/visualboyadvance en dépend déjà.

----------

## PabOu

 *UB|K wrote:*   

> dans l'ebuid de vbaexpress, pourquoi as-tu mis cette ligne:
> 
> ```
> SRC_DIR=${WORKDIR}/${P}
> ```
> ...

 

Je ne sais pas, c'était déjà là :p C'est possible que cela vienne d'un ebuild adapté à partir d'un squelette vide qui contenait cette ligne.

 *UB|K wrote:*   

> - la dépendance sur media-libs/libsdl est inutile car games-emulation/visualboyadvance en dépend déjà.

 

Ok, mais et si games-emulation/visualboyadvance ne dépendait plus de libsdl dans une prochaine version ? vbaexpress en aurais toujours besoin lui.. non ? ce n'est qu'un front-end qui lance une commande après la configuration des paramètres.

----------

## netfab

Mouarf, depuis hier, je me demandais pourquoi je n'arrivais pas à avoir accès aux 2 ebuilds que tu donnes ci-dessus.

 *Quote:*   

> 
> 
> ... bou.pabou.com:1337/gentoo/ ...
> 
> 

 

 :Neutral: 

----------

## PabOu

 *NetFab wrote:*   

> Mouarf, depuis hier, je me demandais pourquoi je n'arrivais pas à avoir accès aux 2 ebuilds que tu donnes ci-dessus.
> 
>  *Quote:*   
> 
> ... bou.pabou.com:1337/gentoo/ ...
> ...

 

euh, ben.. oui ! tiens: http://pastebin.com/657299

 *PabOu wrote:*   

>  *UB|K wrote:*   - la dépendance sur media-libs/libsdl est inutile car games-emulation/visualboyadvance en dépend déjà. 
> 
> Ok, mais et si games-emulation/visualboyadvance ne dépendait plus de libsdl dans une prochaine version ? vbaexpress en aurais toujours besoin lui.. non ? ce n'est qu'un front-end qui lance une commande après la configuration des paramètres.

 

Je devais pas être en forme hier quand j'ai dit ca. En fait vbaexpress n'en aurait plus besoin (et nécessiterait une nouvelle version également) car ca sert à la configuration des touches, afin d'avoir les mêmes valeurs (sdl) dans les 2 programmes.

Je vais donc enlever la dépendance ce soir.

----------

