# emerge --update world : peut on choisir d'éviter un paquet?

## jeurigol

Est il possible de faire un emerge --update world en lui précisant de ne pas emerger un paquet ou faut -il faire emerge --pretend --update world et se taper tous les paquets à la main sauf le(s) indésirable? Je pars en vacances demain, et c'est porquoi je préfèrerai eviter cette dernière solution....

Tans que je vous tiens :

Quelqu'un connait il la différence exacte entre le emerge world et emerge system??? la doc ne m'eclaire pas vraiment à ce sujet... peut etre faudrait il que j'essaye de booter mes neurones ce matin   :Smile: Last edited by jeurigol on Thu Jul 10, 2003 12:42 pm; edited 1 time in total

----------

## mickey08

je suis fort interressé aussi par les DEUX questions  :Smile: 

----------

## Dom

Pour ne pas emerger un packet il y a l'option --inject. Pour faire ton update, tu fait donc "emerge -U world --inject nom_du_packet". Tu peux consulter "man emerge" ou "emerge --help", ce sera mieux expliqué que par moi   :Wink: 

Au passage, le U majuscule dans "emerge -U" permet de remplacer les packets installés uniquement par des versions plus récentes. C'est important si tu as installé des packets ~x86   :Wink:  qui risquent d'être downgradés avec -u.

----------

## Dom

Corrigez-moi si je me trompe mais je crois que "system" regroupe les packets qui constituent le système de base (celui que l'on trouve dans un stage 3 par exemple), alors que "world" désigne le système de base et les packets installés par l'utilisateur (ceux qui ce trouvent dans /var/cache/edb/world). D'ailleurs world ne contient que les packets que l'on a emergé explicitement : si je fais emerge gnome, ça m'installe gnome et sa centaine de dépendances, mais world contient uniquement "gnome".

----------

## yoyo

 *Dom wrote:*   

> Corrigez-moi si je me trompe mais je crois que "system" regroupe les packets qui constituent le système de base (celui que l'on trouve dans un stage 3 par exemple), alors que "world" désigne le système de base et les packets installés par l'utilisateur (ceux qui ce trouvent dans /var/cache/edb/world).

 

Je crois qu'il existe également un fichier system dans ce dossier.

Il me semble d'ailleurs que ces fichiers peuvent être éditer pour voir ce qu'ils contiennent.

 *Dom wrote:*   

> D'ailleurs world ne contient que les packets que l'on a emergé explicitement : si je fais emerge gnome, ça m'installe gnome et sa centaine de dépendances, mais world contient uniquement "gnome".

 

D'où l'intérêt de faire un "emerge -U --deep world" de temps en temps ...

L'option "inject" permet d'ajouter dans /var/cache/edb/world le nom du paquet spécifié dans sa version actuelle. Ainsi, lors du "emerge -u world", il va croire qu'il a déja été installé et ne l'installera pas.

----------

## jeurigol

Si j'ai bien compris vos réponses, update system met à jour le syteme de base, et update world les paquages qu'on a emergé à la mano mais pas ses dépendances....

Dans ce cas qomment TOUT updater???  :Question: 

----------

## Dom

"emerge -U --deep world" doit normalement tout updater.

----------

## Dom

 *yoyo wrote:*   

> Je crois qu'il existe également un fichier system dans ce dossier. 
> 
> Il me semble d'ailleurs que ces fichiers peuvent être éditer pour voir ce qu'ils contiennent. 

 

Le fichier qui liste les packages de la catégorie system est /etc/make.profile/packages. D'après le manuel d'emerge il ne faut pas l'éditer. En revanche on peut rajouter ou enlever des packets du fichier world sans problème.

----------

## yaubi

Pour répondre à la question initiale, tu peux éviter un packet de deux manières :

 - soit en faisant une fausse installation de la nouvelle version du package avec --inject, de manière à ce que que emerge pense qu'il n'est pas nécessaire de le mettre à jour (comme l'a déjà dit Dom)

 - soit en supprimant à la main le package en question du fichier /var/cache/edb/world

S'il s'agit d'un logiciel que tu as installé "pour voir" mais que tu ne veux pas maintenir à jour, il aurait alors été préférable de l'installer avec --oneshot, ce qui "emerge as normal, but do not add the packages to the world profile".

----------

## jeurigol

non en fait c'est pour opera, que je ne veux pas updater parceque je ne supporte pas la vesrion 7...   :Rolling Eyes: 

Je vais lancer tt ca ce soir, je vous ferai mes commentaires dans un mois, si ca interesse quelqu'un.

----------

## TGL

Moi je suis pas trop pour la technique du "inject", parceque mentir à portage c'est s'exposer à des soucis:

 - la vieille version qu'on veut justement garder n'est plus protegée d'un "clean"

 - dans le cas où des paquets dépendent de la nouvelle version qu'on a injectée, portage verra la dépendance satisfaite alors que les paquets risquent de ne pas compiler, ou de ne pas marcher.

Le mieux, si on veut bloquer par exemple Opera à des version inférieures à la 7, c'est de masquer les version à partir de la 7. Ça peut se faire dans /etc/portage/profiles/package.mask, qui est un masque perso qui vient s'ajouter au masque global:

```
# J'aime pas Opera 7 :

>=net-www/opera-7
```

----------

## yoyo

Je l'avais oublié le "portage.mask"   :Embarassed:   :Embarassed: 

Bien vu TGL ...

La route est longue pour devenir un vrai guru   :Laughing: 

----------

## jeurigol

```

-bash: cd: /etc/portage/: No such file or directory

```

c normal ca?

----------

## yoyo

 *jeurigol wrote:*   

> 
> 
> ```
> 
> -bash: cd: /etc/portage/: No such file or directory
> ...

 

Oui puisque normalement, c'est :

/usr/portage

 :Wink: 

PS : Est-ce que tu pourrais formater ton/tes titre(s) comme cela a été défini ici ??

----------

## TGL

Non, c'est bien /etc/portage. Celui dans /usr/portage, c'est le masque par défaut, modifiable aussi mais avec l'énorme inconvénient qu'il est écrasé à chaque sync.

Mais c'est vrai que le répertoire n'existe pas par défaut, il faut se le créer:

```
mkdir -p /etc/portage/profiles
```

Et tant que j'y suis, l'astuce duale de celle ci: on peut mettre dans /etc/portage (sans le "/profiles" cette fois) un fichier package.unmask qui sert à démasquer des ebuilds. Par exemple:

```
# Gimp 1.3, c'est joli sur mes screenshots:

>=media-gfx/gimp-1.3
```

(là, j'autorise gimp-1.3 et supérieur alors qu'il est masqué dans /usr/portage/profiles/package.mask)

----------

## jeurigol

Merci pour le coup du package.mask, c'est effectivemetn bien pratique..

yoyo comment veux tu que je formate ce titre?? moi il parraissait pas mal explicite??

J'ai pas la place de rajouter 

[Question d'intéret Général]

ou 

[nOOb Inside]   :Wink: 

ou meme plus pragmatiquement

[Portage]

mais je suis bien entendu ouvert à toute(s) suggestion(s).

PS:  comment fais-je pour rajouter [résolu], j'ai pas non plus la place?

----------

## yaubi

 *TGL wrote:*   

> Et tant que j'y suis, l'astuce duale de celle ci: on peut mettre dans /etc/portage (sans le "/profiles" cette fois) un fichier package.unmask qui sert à démasquer des ebuilds. Par exemple:
> 
> ```
> # Gimp 1.3, c'est joli sur mes screenshots:
> 
> ...

 

Ah oué, c'est bien ça, j'aime !  :Smile:  merci de l'info TGL !

PS : jerigole, pour le sujet, laisse tomber pour l'instant de toutes manière on est pas encore d'accord sur le format à adopter. Mais c'est vrai que c'est chiant cette histoire de limitation du nombre de caractères.

----------

## jeurigol

tres tres bon le coup du unmask en effet, j'avais pas vu à la première lecture

----------

## michel v

 *jeurigol wrote:*   

> Je vais lancer tt ca ce soir, je vous ferai mes commentaires dans un mois, si ca interesse quelqu'un.

 

A ton retour tu devras sûrement te retaper ça vu qu'il y aura de nouvelles versions de certains packages clé, alors autant ne pas se casser la tête la veille des vacances, non ?  :Wink: 

(Y'a aussi la solution de faire un script lanceur d'emerge, et un job at pour lancer ce script deux jours avant ton retour. En priant pour qu'il n'y ait pas de coupures de courrant et autres blêmes entre temps.)

----------

## TGL

 *michel v wrote:*   

> En priant pour qu'il n'y ait pas de coupures de courrant et autres blêmes entre temps.

 

Mouaif, les emerge dans des cron, je crois vraiment qu'il faut avoir la foi. C'est qd même rare qu'il y ait pas au moins une petite couille sur une grosse update générale. Et puis c'est des coup à avoir effectivement un reboot imprévu alors qu'on a pas encore etc-updaté ses scripts de démarrage, ou ce enre de chose. Bref, danger amha, pour un intérêt assez minime.

----------

## DuF

 *TGL wrote:*   

> 
> 
> Et tant que j'y suis, l'astuce duale de celle ci: on peut mettre dans /etc/portage (sans le "/profiles" cette fois) un fichier package.unmask qui sert à démasquer des ebuilds. Par exemple:
> 
> ```
> ...

 

J'ai essayé de le faire chez moi, mais quand je fais un emerge -p gimp il me propose toujours la version 1.2.4.... j'ai vérifié si le fichier /etc/portage/package.unmask était en lecture pour tout le monde (réponse oui), j'ai essayé en mettant le user portage comme propriétaire du fichier, rien à faire...

Quelle est l'astuce car je suis très intéressé par cette possibilité ?   :Razz: 

----------

## yuk159

je pensais jusque la que pour gimp ce n'etais pas possible etant donne  que portage ne diferencie pas les deux version.(c'etait une hypothese)

mais comme Duf si c'est possible, ca m'interresse de savoir comment   :Wink: 

----------

## TGL

En plus d'être masqués, les ebuilds de Gimp 1.3x sont aussi tildés. Le package.unmask annule le package.mask, mais pas le ~x86. Ça c'est le rôle du ACCEPT_KEYWORDS. Vérifiez aussi que vous avez bien un portage >=2.0.48_pre3 (release où a été introduit le unmask).

Et puis sinon, y'a pas de pb à garder votre Gimp 1.2 en //, puisqu'ils sont slottés, et puis aussi l'executable de Gimp 1.3 s'appelle "gimp-1.3", et puis j'espère que j'oublie rien.

----------

## DuF

OK, je comprends mieux, donc effectivement sans le package.unmask, le dernier gimp instable (~x86) est la version 1.2.5 avec le package.unmask c'est la version 1.3.16 donc voilà c'est good, thx pour les explications TGL.

----------

## yuk159

oui merci Monsieur TGL pour ce cours.  :Very Happy: 

----------

## TGL

 *yuk159 wrote:*   

> oui merci Monsieur TGL pour ce cours. 

 

Yes! La phrase que j'ai toujours rêvé d'entendre de mes élèves !   :Laughing: 

----------

## TGL

 *TGL wrote:*   

> Le mieux, si on veut bloquer par exemple Opera à des version inférieures à la 7, c'est de masquer les version à partir de la 7. Ça peut se faire dans /etc/portage/profiles/package.mask, qui est un masque perso qui vient s'ajouter au masque global:
> 
> ```
> # J'aime pas Opera 7 :
> 
> ...

 

Pour info, je suis passé en portage-2.0.49_preXX, et le /etc/portage/profiles/package.mask est devenu /etc/portage/package.mask. Voilà qui est plus cohérent avec l'emplacement du .unmask.

----------

