# [SCRIPT] Contrôler ses ebuilds d'overlay

## TGL

Hmm... ouaif, il est pas très explicite mon titre... je m'explique...

J'utilise des paquets dans des overlays pour, grosso modo, deux usages :

1) corriger des problèmes avec les ebuilds officiels ; dans ce premier cas, une même version d'ebuild existe à la fois dans l'arbre Portage et dans un overlay, et c'est celle de l'overlay que je veux utiliser, et ça tombe bien puisque c'est comme ça que ça se passe naturellement.

2) ajouter de nouveau paquets ou de nouvelles versions de ceux existant : dans ce cas, l'ebuild n'existe, au début, que dans mon overlay, et c'est de là qu'il est installé. Mais par la suite, il peut arriver dans Portage... À ce moment là, celui de mon overlay est redondant, et souvent moins bon (genre c'est une version que j'ai proposé sur Bugzilla, et qui a été intégrée avec quelques améliorations/corrections dont je voudrais profiter, ou au moins tester). Mais évidemment, si je réinstalle le paquet, c'est toujours la version de l'overlay qui est utilisée, jusqu'à ce que je la supprime manuellement.

Pour me faciliter un peu la tâche de la détection du cas n°2, j'ai un petit script qui permet de lister les paquets installés dont l'ebuild existe à plusieurs endroits (plusieurs overlays, ou bien un overlay et l'arbre Portage). C'est pas grand chose, mais bon, je viens de le compléter/nettoyer un peu, et j'ai pensé que ça pouvais être utile à d'autres, donc le voilà : 

```
#!/bin/bash

# Copyright 2006 Thomas de Grenier de Latour (TGL) <degrenier@easyconnect.fr>

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

PROG_NAME=$(basename ${0})

show_help() {

   cat << EOF

Usage:

  ${PROG_NAME} [-e] [<category> ...]

  ${PROG_NAME} -h

Options:

  -e, --exact-version  Only show repositories with ebuilds in the exact 

                       installed version. (Hide "[~]" results.)

  -h, --help           Show this help message.

This program checks your installed packages and reports about ebuilds which

exist in several locations (PORTDIR or overlays).  If no <category> parameter

is given, then all installed packages are checked, and otherwise, only the 

ones of the specified categories are.

Output is as follows:

| category/package-X.Y:

|   [+] /location/of/an-overlay

|   [+] /location/of/another-overlay

|   [~] /usr/portage

It means that the package was installed from "an-overlay" (first listed), but

also exists in "another-overlay" in the exact same version ("[+]"), and in a

different version ("[~]") in the official Portage tree.  The repository from

where the ebuild has been installed ("an-overlay") could also have been marked

with a "[-]" if there was no more such package there, or "[!]" if it was not 

existing at all anymore.

EOF

}

usage_error() {

   cat << EOF >&2

${1}: unknown option. Use --help for help.

EOF

}

while [[ $# -gt 0 ]] ; do

   case ${1} in

      -h|--help) show_help ; exit 0 ;;

      -e|--exact-version) EXACT_ONLY=yes ; shift ;;

      --) shift ; break ;;

      -*) usage_error "${1}" ; exit 2 ;;

      *) break ;;

   esac

done

REPOSITORIES="$(portageq portdir) $(portageq portdir_overlay)"

cd "$(portageq vdb_path)"

unset INSTALLED_PKGS

[[ $# -le 0 ]] && INSTALLED_PKGS=$(ls -d *-*/*-*)

while [[ $# -gt 0 ]] ; do

   INSTALLED_PKGS="${INSTALLED_PKGS} $(ls -d ${1}/*-* 2>/dev/null)"

   shift

done

for pkg in $INSTALLED_PKGS ; do

   envbz="${pkg}/environment.bz2"

   [[ ! -f ${envbz} ]] \

      && echo "${pkg}: can't find 'environment.bz2'. Skipping." >&2 \

      && continue

   ebuild_abspath=$(bzgrep -m1 '^EBUILD=' ${envbz})

   ebuild_abspath="${ebuild_abspath##EBUILD=}"

   [[ -z ${ebuild_abspath} ]] \

      && echo "${pkg}: can't read ebuild path. Skipping." >&2 \

      && continue

   catpkg="${pkg%-[0-9]*}"

   ebuild_relpath="${catpkg}/${ebuild_abspath##*/}"

   install_repo="${ebuild_abspath%%/${catpkg}/*}"

   unset other_output

   for repo in ${REPOSITORIES} ; do

      [[ "${repo}" == "${install_repo}" ]] && continue

      [[ -f "${repo}/${ebuild_relpath}" ]] \

         && other_output="${other_output}\n  [+] ${repo}" \

         && continue

      [[ -z "${EXACT_ONLY}" ]] && [[ -d "${repo}/${catpkg}" ]] \

         && other_output="${other_output}\n  [~] ${repo}"

   done

   [[ -z "${other_output}" ]] && continue

   if [[ -f "${install_repo}/${ebuild_relpath}" ]]; then

      echo -ne "${pkg}:\n  [+] ${install_repo}"

   elif [[ -d "${install_repo}/${catpkg}" ]]; then

      echo -ne "${pkg}:\n  [~] ${install_repo}"

   elif [[ -d "${install_repo}" ]] ; then

      echo -ne "${pkg}:\n  [-] ${install_repo}"

   else

      echo -ne "${pkg}:\n  [!] ${install_repo}"

   fi

   echo -e "${other_output}"

done
```

 Je vous laisse lire le message d'aide au début du script pour les détails, je pense pas qu'il y ait grand chose de subtil à expliquer là dedans.

Après, à l'usage, bah il s'agit juste de regarder la sortie en essayant de se souvenir de pourquoi on a le paquet dans son overlay. 

```
% find-duplicate-installed-ebuilds.sh -e

...

app-editors/gvim-6.4:

  [+] /var/portage/overlays/tgl

  [+] /var/portage/tree

...

app-vim/cream-0.34:

  [+] /var/portage/overlays/tgl

  [+] /var/portage/tree
```

 Pour GVim, je sais que c'est en overlay parceque j'applique quelques patchs persos, donc rien à signaler. Par contre, Cream c'était un bump d'ebuild de mon cru, et maintenant qu'il est dans Portage (ouais, c'est /var/portage/tree chez moi au lieu de l'habituel /usr/portage), je pourrais aussi bien le virer de là (ce que je vais faire tout de suite d'ailleurs).

Et puis voilà, c'est tout pour aujourd'hui. Mais j'ai quelques autres oneliners crados qui trainent et qui servent eux aussi à des tâches proches (genre détecter les paquets d'overlay non installés, etc.), donc je collerai ça ici aussi quand j'aurai trouvé le courage d'en faire des scripts ~présentables.

Et si vous avez vous aussi des scripts ou astuces à ce sujet, et bah n'hésitez pas, enfin moi en tout cas ça m'intéresse...

EDIT : s/skip/shift/, merci aux betatesteurs vigilants.Last edited by TGL on Fri Apr 28, 2006 6:11 pm; edited 1 time in total

----------

## truc

Merci beaucoup, ça faisait un moement que je voulais l'essayé.. et finalement c'est fait  :Smile:  Alors, ça m'a permis de faire le ménage un peu, d'enlever notament des paquets installés par l'overlay de xgl-coffee, et qui était slottés, donc même après avoir viré l'overlay, il restait quelques résidus..

Merci, bon boulot:) j'aurai aimé avoir un commentaire constructif à faire mais j'vois pas..

Ah si, je demande l'authorisation de lui éborgner légèrement son nom, car il commence par find.. ça m'embète un peu.. Na!

EDIT:Juste un question rapide quand même:

```
    --) skip ; break ;;
```

 ce skip c'est quoi normalement car, j'ai consciemment essayé du coup et...

```
$ find-duplicate-installed-ebuilds --

/home/scripts/find-duplicate-installed-ebuilds: line 47: skip: command not found

```

 :Question: 

----------

## Ey

 *truc wrote:*   

> EDIT:Juste un question rapide quand même:
> 
> ```
>     --) skip ; break ;;
> ```
> ...

 

Faut le remplacer par un shift sauf erreur de ma part...

le -- c'est pour lui dire que ce qui suit est forcément plus une option, donc tu shift le -- pour passer à l'arg suivant puis le break pour terminer la lecture des options

----------

## truc

ça me semble logique.. merci:) j'n'y avais pas pensé..

----------

## PabOu

yop ;)

Chouette script sauf qu'il ne fonctionne pas comme voulu chez moi...

Je lance le script sans lui ajouter de paramètres et voici ce qu'il me sort : *le script de TGL wrote:*   

> root@framboise ~ # ./find-duplicates-installed-ebuilds.sh
> 
> app-arch/cpio-2.6-r5:
> 
>   [+] /usr/portage
> ...

 

Aucun des paquets cités ne se trouve dans mon world.

J'ai beaucoup plus de paquets que ca d'installés ;)

mon /usr/portage est un lien vers /mnt/hdc1/portage

mon make.conf contient ces lignes :

```
PORTDIR="/mnt/hdc1/portage"

DISTDIR="/mnt/hdc1/portage-distfiles"

PORTDIR_OVERLAY="/usr/local/portage/overlays/PabOu"
```

Je n'ai rencontré aucun problème avec emerge et cette configuration

C'est de ma faute ou il n'est pas gentil avec moi le script ? :(

----------

## truc

Je ne suis sans doute pas à même de t'aider mais par curiosité, que te renvoient ces commandes:

```
portageq portdir

portageq portdir_overlay

portageq vdb_path
```

Et en fait je me demande, ce /mnt/hdc1/portage, c'est un  truc que tu as fais par la suite n'est ce pas? (ça n'a pas toujours été comme ça?) depuis que tu l'as fais je suppose que tu n'as jamais fais de emerge --emptytree ? Je pense que dans ton "vdb_path (souvent /var/db/pkg) tu dois avoir la trace de packets qui ont été installés alors que tu avais encore ton arbre dans /usr/portage.

Relance le script, en ayant supprimer ton lien /usr/portage et dis nous ce que ça te donne.

----------

## PabOu

 *truc wrote:*   

> Je ne suis sans doute pas à même de t'aider mais par curiosité, que te renvoient ces commandes:
> 
> ```
> portageq portdir
> 
> ...

 

Rien d'anormal...

```
root@framboise ~ # portageq portdir

/mnt/hdc1/portage

root@framboise ~ # portageq portdir_overlay

/usr/local/portage/overlays/PabOu

root@framboise ~ # portageq vdb_path

/var/db/pkg
```

 *truc wrote:*   

> Et en fait je me demande, ce /mnt/hdc1/portage, c'est un  truc que tu as fais par la suite n'est ce pas? (ça n'a pas toujours été comme ça?) depuis que tu l'as fais je suppose que tu n'as jamais fais de emerge --emptytree ? Je pense que dans ton "vdb_path (souvent /var/db/pkg) tu dois avoir la trace de packets qui ont été installés alors que tu avais encore ton arbre dans /usr/portage.
> 
> Relance le script, en ayant supprimer ton lien /usr/portage et dis nous ce que ça te donne.

 

Euh, si, ca à toujours été comme ca, depuis l'install. Je n'ai rien emergé avant de déplacer mon PORTDIR. Mais il est vrai que je n'ai jamais fait de emerge -e ... et peut-être que certains paquets qui viennent du stage (stage 3 suivi d'un bootstrap.sh) ont été compilés avec un PORTDIR original (/usr/portage).

Quoiqu'il en soit, j'ai essayé de retirer le lien /usr/portage, et le résultat est presque le même. Ce sont les mêmes paquets mais avec un output différent :

```
app-arch/cpio-2.6-r5:

  [!] /usr/portage

  [+] /mnt/hdc1/portage
```

Et pour deux d'entre eux, c'est encore différent :

```
app-crypt/hashalot-0.3-r1:

  [!] /usr/portage

  [~] /mnt/hdc1/portage
```

J'ai été voir par curiosité dans /var/db/pkg/app-arch/cpio-2.6-r5 et aucun fichier ne contient de référence au PORTDIR (original ou le mien). Cela doit donc venir d'ailleurs.

J'ai une autre question : il est normal d'avoir autant de versions de sys-devl/automake ? 

```
1.8.5-r3 1.9.6-r2 1.6.3 1.7.9-r1 1.4_p6 1.5
```

----------

## truc

 *PabOu wrote:*   

> J'ai une autre question : il est normal d'avoir autant de versions de sys-devl/automake ? 
> 
> ```
> 1.8.5-r3 1.9.6-r2 1.6.3 1.7.9-r1 1.4_p6 1.5
> ```
> ...

 

En attendant que TGL nous vienne en aide.. je peux quand même essayer de répondre à ça.. --> Oui c'est normal, car les differents paquets automake ne sont pas toujours compatible entre eux, et un paquet(un autre) peut demander une version particulière de automake pour pouvoire (être) compile(r).

----------

## TGL

 *truc wrote:*   

> En attendant que TGL nous vienne en aide.. 

 

Oups, déso pour le silence, je ne découvre qu'aujourd'hui qu'il y a eu des réponses à ce thread. J'ai probablement zappé le mail de notification...

Bref, donc, bon, déjà, merci truc et ey pour le coup du "skip". C'est bien "shift" qu'il faut lire, je vais corriger de ce pas (et me flageller un peu pour avoir zappé les tests unitaires sur le parsing des options... non mais franchement, la qualité logicielle c'est plus ce que c'était...)

@PabOu : je pense effectivement que les /usr/portage viennent de paquets du stage3, qui n'ont jamais  été écrasés par des versions installées depuis ton /mnt/hdc1/portage. Enfin je peux me gourrer, mais si tu n'as pas trouvé de référence à /usr/portage dans la VDB, c'est à mon avis simplement parcequ'elles sont cachées dans les fichiers "environment.bz2" des paquets, donc hors de portée d'un simple grep. Essaye plutôt voir ça : 

```
% bzgrep "^PORTDIR" /var/db/pkg/app-arch/cpio-2.6-r5/environment.bz2
```

 Si c'est bien le cas, alors les deux sorties que tu obtiens sont normales, quoi que effectivement pas très utiles... :

 - avec le symlink, on a 2 fois des "[+]", parcequ'on trouve 2 ebuilds, via des chemins différents. Bon, ok, dans ce cas précis on pourrait envisager un truc avec realpath pour détecter que c'est en fait un seul et même fichier, mais la flemme...

 - sans le symlink, on détecte que le paquet a été installé depuis un repository qui n'existe plus, d'où le "[!]". Là encore, dans ton cas c'est pas terrible... Perso j'envisageais plus cette indication pour repérer des paquets qui ont été installés, par exemple, depuis un overlay qu'on a ensuite décidé de virer (et que donc on peut avoir envie de réinstaller depuis l'arbre officiel, histoire de revenir à un truc propre). Mais je vois pas comment éviter du coup que ça fasse des fausses alertes dans ton cas... Si vraiment ça te dérange, tu es bon pour réinstaller les qlqs paquets concernés, comme ça il n'y aura plus aucun /usr/portage dans ta VDB  :Smile: 

 *truc wrote:*   

> Oui c'est normal, car les differents paquets automake ne sont pas toujours compatible entre eux, et un paquet(un autre) peut demander une version particulière de automake pour pouvoire (être) compile(r).

 

Et bah voilà, pas mieux, tout est dit.  :Wink: 

----------

## PabOu

Effectivement, c'est caché dans le fichier .bz2

Ca ne me dérange pas que ce soit installé à partir de /usr/portage, par contre, ca me dérange que ca n'ait pas été recompilé avec MES options. je vais donc me faire un emerge world -e ..

edit: truc, oui, je comprends mieux, j'avais juste zappé le fait que c'était slotté (je sais pas pourquoi, avec le emerge -Cpv j'ai du penser que ca affichait les slots si c'était avec des ebuilds slottés.. mais en fait non).

Merci à vous pour les réponses, et encore bravo pour le script.

----------

## TGL

 *PabOu wrote:*   

> ca me dérange que ca n'ait pas été recompilé avec MES options. je vais donc me faire un emerge world -e ..

 

Bof, un "-e world" juste pour ça, faut avoir du temps CPU à perdre à mon avis :

 - pour les trucs compilés avec les mauvais USE flags, "emerge -N" fait déjà des merveilles.

 - pour les trucs compilés avec les mauvais {C,CXX,LD}FLAGS, il est assez possible de les repérer dans cette VDB dont tu viens de découvrir les secrets, et donc de ne recompiler que ceux là. Je pense qu'il y a déjà des scripts tout prêts pour ça qui trainent, ou sinon au pire ça n'est vraiment pas bien dur à faire (hésite pas à ouvrir un topic sur le sujet si tu ne t'en tires pas tout seul).

----------

## PabOu

Je préfère un -e world, pour être sur que les applications qui les ont en dépendance vont en profiter. Et puis ce n'est pas sur ma station de travail, donc si ca utilise du CPU (avec un nice à 15), je ne le remarquerai pas.

Pour les useflags, j'utilise toujours le -N (et le -D) à chaque mise à jour, donc j'ai tout bon de ce coté.

Pour les autres (les flags), je n'ai vraiment rien emergé avant de déplacer mon /usr/portage et de modifier mon make.conf. Il me suffit donc de regarder la liste donnée par ton script, et de faire un emerge -1. Non ? De toute façon, mon emerge -e world est déjà lancé.

----------

