# [portage] xeffects et kde

## aconcagua

Bonjour à tous !

J'ai ajouté l'overlay xeffects à layman (pour compiz fusion).

Le problème est qu'il veut réemerger certains package kde lorsque je fais  

```

#emerge -uDNav world

[ebuild   R   ] kde-base/konqueror-3.5.7-r2  USE="branding xinerama -arts -debug -java -kdeenablefinal -kdehiddenvisibility -pertty%" 0 kB [2]

[2] /usr/portage/local/layman/xeffects

```

La version actuelle installée est celle venant de gentoo et je n'ai pas particulièrement envi de la remplacer par celle de xeffects.

```

# eix konqueror

[UD] kde-base/konqueror

     Available versions:

        (3.5)   3.5.5 ~3.5.6 ~3.5.6-r1 ~3.5.7 ~3.5.7-r1 3.5.7-r2

        (0)     3.5.7-r2[1]

        {arts branding debug elibc_FreeBSD java kdeenablefinal kdehiddenvisibility pertty xinerama}

     Installed versions:  3.5.7-r2(3.5)(15:03:12 19.08.2007)(-arts branding -debug -elibc_FreeBSD -java -kdeenablefinal -kdehiddenvisibility xinerama)

     Description:         KDE: Web browser, file manager, ...

```

Comment faire ?

Merci ...

----------

## ghoti

Ton problème est dû au flag "pertty" dans l'overlay, qui n'existe pas dans la version officielle.

Lorsqu'il y a ambiguïté, c'est toujours l'overlay qui est préféré et vu que tu utilises l'option "-N", emerge estime qu'il doit recompiler le paquet puisqu'il a un nouveau flag.

Perso, je ne connais pas de moyen de masquer sélectivement les packages venant des overlays (mais ça ne veut pas dire qu'il n'y en a pas - ça m'intéresse, d'ailleurs !  :Wink:  )

Si tu veux absolument garder la version officielle, je ne vois perso qu'une solution assez crasse : virer aussi brutalement que manuellement le "konqueror" de l'overlay !

Evidemment, il faudra penser à le faire chaque fois que tu mettras l'overlay à jour !

----------

## Tuxicomane

Salut,

C'est ptêt idiot ce que je vais dire, mais comme les nouvelles versions de Portage autorisent les entrées du genre 

```
sys-devel/gcc:4.1
```

 dans le fichier world et que je vois que l'ebuild de l'overlay est dans un slot, est-ce qu'un

```
emerge -vn konqueror:3.5
```

ne résoudrait pas le problème en empêchant les ebuilds du SLOT 0 de s'installer ?   :Confused: 

----------

## tarpman

Absolument, mais c'est toujours possible qu'on va ajouter le konqueror d'xeffects au SLOT 3.5 (selon moi il devrait y être déjà...).  Portage ne peut pas vraiment masquer des paquets selon d'ou ils viennent; si tu veux cela il faudrait peut-être essayer paludis.

----------

## aconcagua

Merci à tous pour vos réponses.

Pour le moment j'ai ajouté à package.mask :

```

kde-base/konqueror:0

```

Mais c'est sûr que si xeffect met konqueror dans le slot 3.5, çà ne fonctionnera plus

----------

## aconcagua

Bon finalement, çà marche pour konqueror mais pas pour qt.

```

[I] x11-libs/qt

     Available versions:

        (3)     3.3.4-r8 3.3.8-r2 3.3.8-r2[2] 3.3.8-r3 3.3.8-r3[2]

        (4)     4.2.3-r1 4.3.0 ~4.3.0-r1 4.3.0-r2 ~4.3.1

[2] /usr/portage/local/layman/xeffects

```

Là ma version 3.3.8-r3 et la version 3.3.8-r3 de xeffects sont dans le même slot

----------

## Temet

Prends les ebuilds que t'as besoin, fous les dans ton overlay local et vire xeffects.

Tu gagneras du temps... en fait ce serait déjà résolu!

Je crois qu'il manque un paramètre à portage pour la gestion des overlays.

----------

## xaviermiller

Ouais, la politique actuelle est "tout ce qui est dans un overlay n'est pas supporté et on s'en fout". Dommage, car pour l'instant c'est surtout dans les overlays que ça bouge...

----------

## Temet

Erf, va vraiment falloir que je me tire les doigts et me pose une Arch moi ...  :Sad: 

----------

## Tuxicomane

 *XavierMiller wrote:*   

> Ouais, la politique actuelle est "tout ce qui est dans un overlay n'est pas supporté et on s'en fout". Dommage, car pour l'instant c'est surtout dans les overlays que ça bouge...

 Ce qui est bien dommage, car les overlays, c'est vraiment génial ..

Ce dont je rêve, c'est un arbre Portage limité au strict minimum ( donc sans ebuild pour softs proprios) auquel on pourrait ajouter des overlays qui nous intéressent, officiels ou non ... Bon ok, ça ressemble un peu à ce qui se fait chez les Debian-like mon truc, mais je crois que ça arrangerais tout le monde (allègement de l'arbre déjà ...).

----------

## SanKuKai

 *Tuxicomane wrote:*   

> Ce qui est bien dommage, car les overlays, c'est vraiment génial ..
> 
> Ce dont je rêve, c'est un arbre Portage limité au strict minimum ( donc sans ebuild pour softs proprios) auquel on pourrait ajouter des overlays qui nous intéressent, officiels ou non ... Bon ok, ça ressemble un peu à ce qui se fait chez les Debian-like mon truc, mais je crois que ça arrangerais tout le monde (allègement de l'arbre déjà ...).

 

Bah moi déjà ça ne m'arrangerait pas du tout.   :Laughing: 

Si y'a bien un truc qui m'horripilait chez Debian & co, c'est le fait de devoir chopper par-ci, par-là des dépots vaseux pour installer des softs.

«- Comment je fais pour lire mes dvd ? »

«- Bah installer le dépot multimédia de machin »

«- Et pour les drivers proprios de ma carte graphique »

«- Là il te faut le dépôt de bidule  »

etc.

Ajoute à ça les dépots tellement mal fichus qui contiennent des softs mais pas leurs dépendances et que ces dépendances ne sont pas assez récentes dans le dépot officiel. Beurk !

Non vraiment ce que j'apprécie le plus sous Gentoo et FreeBSD c'est d'avoir à disposition une quantité colossale de softs sans me prendre la tête et libre à moi de ne pas remonter toute l'arborescence de ports ou tout l'arbre Portage pour éviter la lourdeur.

----------

## Temet

+1 !!!

Le dépot centralisé est une des caractéristiques les plus attrayantes sur Gentoo!

J'ai toujours détesté me battre avec les dépots, souvent incompatibles entre eux qui plus est.

----------

## Tuxicomane

 *Quote:*   

> libre à moi de ne pas remonter toute l'arborescence de ports ou tout l'arbre Portage pour éviter la lourdeur.

 Vu comme ça, je dis oui.

Si tu n'utilise rien de KDE, tu bloques toutes la catégorie OK.

Mais éviter tous les ebuilds de softs proprios, tu fais comment ?  :Very Happy: 

----------

## Temet

Bah tu ne les installes pas.

Les ebuilds ne sont pas propriétaires.

T'ain de la merde, pas envie de me retrouver avec un overlay "bouçapuçaypalibre".

----------

## Tuxicomane

@ Temet : non mais en fait je chipote un peu, c'est juste parce que c'est des machins qui ne me serviront jamais, qui ralentissent mes emerge --sync et qui prennent de la place  :Very Happy: 

Sinon, bien sûr que les ebuilds des dits programmes ne sont pas propriétaires, encore heureux d'ailleurs ...  :Smile: 

----------

## aconcagua

Moi je trouve intéressant les overlays lorsque les ebuilds ne sont pas encore dans le dépôt officiel. Mais avec xeffects, je ne comprends pas trop pourquoi il y a des ebuilds concurrents de ceux de portage (même version).

Ils ajoutent peut-être des options (d'où des use-flags différents) mais en tout cas çà fout le boxon.

----------

## ghoti

 *aconcagua wrote:*   

> ils ajoutent peut-être des options (d'où des use-flags différents)

 

Exactement : pour konqueror, le flag pertty permet d'ajouter un patch qui semble avoir trait au panneau latéral. On ne peut donc pas dire que c'est la même version que l'officielle !

Maintenant, il a toujours été dit qu'en installant des trucs "non officiels", on acceptait le risque d'une certaine complication. 

Il ne faut pas espérer avoir le beurre et l'argent du beurre (plus le sourire de la crémière etc. ...)

A toi de voir donc ...

----------

## aconcagua

Du coup j'ai créé un petit script bash qui :

- met à jour mes overlay avec layman -S

- récupère le nom des différents overlays en listant les répertoires dans /usr/portage/local/layman

- pour chacun des overlays, si le fichier /etc/portage/${OVERLAY}.mask existe , supprime chacun des packages présent dans le fichier 

```

#!/bin/sh

ETC_PORTAGE_DIR=/etc/portage

LAYMAN_DIR=/usr/portage/local/layman

RemovePackage() {

    CATEGORY="${2%/*}"

    PACKAGE_VERSION="${2#*/}"

    EBUILD_FILE=`find "${LAYMAN_DIR}/${1}/${CATEGORY}" -name "${PACKAGE_VERSION}.ebuild"`

    if [ ${EBUILD_FILE} ] ; then

        rm "${EBUILD_FILE}"

    else

        echo "Cannot find ${2}"

    fi

}

# directories in LAYMAN_DIR are the names of the overlays

find "${LAYMAN_DIR}" -mindepth 1 -maxdepth 1 -type d -printf "%f\n" | while read OVERLAY ; do

#    echo "repository : ${OVERLAY}"

    if [ -f "${ETC_PORTAGE_DIR}/${OVERLAY}.mask" ] ; then

        echo "Removing masked packages from overlay ${OVERLAY} ..."

        grep "^[^#]" "${ETC_PORTAGE_DIR}/${OVERLAY}.mask" | while read PACKAGE ; do

            RemovePackage "${OVERLAY}" "${PACKAGE}"

        done

    fi

done

```

Mon fichier /etc/xeffects.mask est le suivant :

```

kde-base/libkonq-3.5.7

kde-base/kdelibs-3.5.7-r2

kde-base/kicker-3.5.7

kde-base/kcontrol-3.5.7-r1

x11-libs/libXft-2.1.12

x11-libs/cairo-1.4.10

x11-libs/qt-3.3.8-r3

x11-libs/gtk+-2.10.13

x11-wm/metacity-2.18.5

kde-base/konqueror-3.5.7-r2

kde-base/kdesktop-3.5.7

kde-base/kdm-3.5.7

kde-base/ksmserver-3.5.7

```

History :

- 30 aout : version initiale

- 31 aout : correction bug in RemovePackage

- 4 septembre : utilisation de find pour trouver le package

----------

## aconcagua

J'ai mis à jour le script.

Il peut être intégré à eix-sync :

- l'enregistrer dans /usr/bin/layman-masked

- créer ou éditer /etc/eix-sync.conf :

```

*

!layman-masked

```

----------

