# [Portage] Quoi de neuf dans le 2.0.50 ?

## TGL

sys-apps/portage-2.0.50, la nouvelle version stable de votre gestionnaires de paquets vient de sortir aujourd'hui. Copiant sans honte l'idée que Genone avait eu dans ce thread, je vous propose une petite introduction aux nouveautés apportées par cette version, parceque je sais bien que la plupart d'entre vous ne lisent pas le ChangesLog, et ignorent à quel point ils ont tord. Alors, en vrac (enfin pas tout à fait, le plus important d'abord quand même, approximativement et subjectivement) :

 - portage.5 :  Voilà qui manquait cruellement dans les versions précédentes, une page de manuel expliquant le rôle des différents fichiers utilisés par portage, et leur syntaxe. Beaucoup des fichiers qui sont décrits là existent depuis longtemps (la plupart des fichiers de profile par exemple), d'autres ont été introduits récemment seulement (/etc/portage/package.{mask,unmask} avec la version 2.0.49) mais n'étaient que trop peu connus de par l'absence de leur documentation, et enfin quelques uns sont vraiment nouveaux (cf. ci dessous). Bref, à lire absolument, ça répondra à pas mal de «comment on fait pour...».

 - /etc/portage/package.use :  Et non, vous ne rêvez pas, on peut maintenant activer/désactiver des USE flags pour certains paquets particuliers. Par exemple, moi j'utilise ce fichier parceque le  flag "doc" ne m'intérresse que pour qlqs langages et librairies que j'utilise, mais pas les autres applis en général. Ou encore j'y désactive "gtk2" pour Mozilla (parceque je n'arrive toujours pas à me faire à Galeon 1.3 et qu'il faut une version gtk1 pour compiler Galeon 1.2), alors que le reste de mon système utilise gtk2. Bref, avec ça, fini les USE="foo -bar" sur la ligne de commande.

 - /etc/portage/package.keywords :  C'est LA solution pour mixer proprement du stable (arch) et de l'instable (~arch) sur votre système. Jusqu'ici, vous avez utilisé des ACCEPT_KEYWORDS="~arch" en ligne de commande, qui vous condamnaient à ne faire ensuite plus que des "emerge -uU world" pour éviter de voir les versions instables désinstallés. C'était Mal(tm) : le "-U", il n'est bon qu'à cacher le fait que par exemple un paquet doit réellement être downgradé à cause d'une incompatibilité avec autre chose, bref c'était de la bidouille. Ou pire, vous avez fait des "emerge /path/to/the/file.ebuild", et après vous vous êtes étonnés d'avoir des problème avec les paquets virtuels ou le fichier world, etc. Fini tout ça... Vous êtes en stable mais vous voulez quelques paquets de tests ? Déclarez les ici, et utilisez emerge normalement. Ou bien vous êtes en tildarch, mais vous voulez un gcc et une glibc stable ? Pareil, dîtes le là, ça suffira.

 - /etc/portage/mirrors :  Ce fichier permet de choisir ses mirroirs préferrés pour tout ce qui est sourceforge, gnu, kernel, gnome, kde, etc., bref toutes les URLs de type mirror://qqch. Je posterai plus tard (quand il sera fini) mon propre fichier, ou j'ai sélectionnés les mirroirs français. On peut aussi y déclarer un mirroir spécial, "local", qui à la priorité sur tout les autres : c'est extrêmement pratique si vous avez un réseau local avec un distfiles partagé par exemple en FTP.

 - buildsyspkg :  Ce nouveau FEATURES flag ordonne à emerge de créer des binaires de sauvegarde pour tous les paquets de la classe system. Comme ça, le jour où vous installez un gcc buggué, ou que vous effacez un fichier de portage, etc, vous pouvez en principe vous en sortir et revenir facilement à l'une des versions sauvegardées. Si vous faîtes de temps en temps le ménage des vieilles versions, ces paquets devraient occuper de l'ordre de 200 ou 300Mo à tout casser, un bon investissement je pense.

 - protection des modules :  Vous avez probablement remarqué que quand on utilise plusieurs noyaux simultanément (disons un 2.4-gentoo et un 2.4-ck), avec des modules externes (disons alsa), l'installation des modules pour l'un nettoie les modules de l'autre. Après deux ans de tergiversations stériles sur ce problème exaspérant, un fix crade à finalement vu le jour, qui consiste à ne pas nettoyer les fichiers de /lib/module. Pas trop tôt, mais on est content quand même.

 - emerge --ask :  On vous l'a dit 100 fois, il faut toujours faire "emerge --pretend" avant de faire "emerge" pour de vrai... Et bien désormais, avec "emerge --ask" ("-a" pour les intimes), vous ferez d'une pierre deux coups : les paquets à installer/désinstaller seront listés, et ensuite on vous demandera de confirmer si ça vous plait. L'avantage est que les dépendances ne sont calculées qu'une fois bien sûr. Bref, une bonne option pour les flemmards.

 - emerge {-p,-a} --tree :  Ce "--tree" est un nouveau mode d'affichage des listes de paquets, sous forme d'arbre de dépendances. Il devrait aider à répondre au fameux problème de la peau de Roger Rabbit. Bon, c'est pas parfait cependant, vu que les dépendances telles que emerge se les représentent ne forment pas un arbre complet, mais c'est mieux que rien et ça marche souvent. Et puis c'est joli quand on le fait avec "-uD world".

 - affichage des overlays :  En mode verbeux ("-v"), un "emerge --pretend" affiche maintenant d'où provient un ebuild quand il ne vient pas de l'arbre portage mais d'un de vos PORTAGE_OVERLAY, bref quand c'est un ebuild à vous. Au fait, vous ne saviez pas que PORTAGE_OVERLAY était une liste de répertoires et non un répertoire unique, hein ? Et bah maintenant vous le savez. 

 - affichage de la taille des téléchargements :  Toujours en mode "-pv", emerge affiche maintenant la taille des fichiers à télécharger pour chacun des paquets qu'il va installer. Bon, y'a un petit bug qui est passé à la trappe (parfois il affiche des downloads qui n'auront pas lieu parcequ'on est pas concerné pour cause de USE flags), mais je ne déséspère pas de voir le fix accepté un jour.

 - affichage des licences:  Les résultats d'un recherche avec "emerge -s" contiennent maintenant la/les licences sous lesquels les paquets sont distribués. Très bien ça si vous cherchez un soft quelconque mais que vous le voulez absolument libre parceque sinon beurk.

 - déprécation de profiles :  Ça se dit «déprécation» ? Ou bien «dépréciation» peut-être... bon, on s'en fout, ce qu'il faut savoir c'est que ça consiste à pousser les vieux gentooeurs à mettre à jour leur installation vers un profile plus récent. Je fais partie des victimes avec une machine installée y'a deux ans, en gcc-2.95 et tout et tout. Grrr... la flemme...

 - options de rsync :  Vous pouvez maintenant dans make.conf définir une limite de bande passante consommable par "emerge sync". En plus, les options de verbosité d'emerge ("-q", rien, "-v") ont maintenant effet sur celle de rsync.

 - un repoman plus méchant :  Pour ceux qui ne savent pas, il s'agit de l'outil que les développeurs utilisent pour contrôler la qualité de leurs ebuilds, les ajouter dans l'arbre, tout ça quoi. Et bah maintenant il est devenu bien plus sévère sur ce qu'il contrôle, donc voilà, les développeurs n'ont qu'à bien se tenir. Notez quand même que vous aussi vous pouvez jouer depuis chez vous en appelant le 08.33.... mais qu'est-ce que je dis moi ? Pouf pouf. Notez que vous aussi vous pouvez utiliser cet outil pour contrôler vos ebuilds tout beaux tout neufs avant de les soumettre sur bugzilla.

 - plein de remaniments du code :  C'est la partie cachée de l'iceberg... Il faut avoir ouvert une fois au moins le fichier "portage.py" pour comprendre de quel genre de refactoring à la tronçonneuse il a besoin ; et bah dîtes vous que ça a un petit peu avancé. Pour ceux que ça intérresse, sachez qu'on approche doucement d'un code thread safe (donc que par exemple les downloads simultanés aux compilations devraient un jour être possibles), plus modulaire, testable par modules, mieux documenté... Mais bon, là je rentre dans le work in progress, c'est pas le sujet.

 - plein de bugs fixés :  On vous avait pas dit que portage c'était tout buggué ? Et bah ça l'est moins maintenant, enfin, jusqu'à preuve du contraire...

 - un nouveau gentoolkit :  Et oui, la série 0.2.x de app-portage/gentoolkit arrive, en exclusivité pour portage-2.0.50. Au programme, de nouveaux outils, comme "equery" (un genre de remplaçant tout nouveau tout beau pour qpkg et etcat), et puis une jolie librairie python pour unifier un peu plus les dits outils. 

Voilà voilà, j'en oublie forcement, alors hésitez pas à compléter. Mais c'est déjà assez long comme ça, j'ai même la flemme de faire ma passe orthographique.  :Embarassed: 

Je stick pour quelques jours, histoire d'être sur que tout le monde aura vu au moins que "man portage" est notre nouvel ami.

 - EDIT :  j'oubliais la feature qui tue : les messages de debug d'ebuilds. Si vous avez des bizarreries du genre «has_version() in global scope: foo/bar-1.2.3» ou encore des USE flags qui s'affichent n'importe quand, vous vous affolez pas, ça mord pas, it's not a bug it's a feature.

 - EDIT bis :  ah oui, une autre feature aussi... Il se peux que certains d'entre vous voient de temps en temps des plantages avec un trace vous parlant d'une "exception KeyError". Ça, c'est en général quand portage recontre quelquepart une spécification de paquet de type categorie/paquet-x.y.z. Ça a été une façon légale de spécifier une version précise avec les précédents portage, mais ça ne l'est plus, et ça devrait être maintenant =categorie/paquet-x.y.z. Si ça n'est pas sur la ligne de commande que vous avez passé un truc de ce genre, alors cherchez le du côté de votre world, ou dans vos fichiers de /etc/portage. L'erreur est pas très jolie vu qu'elle n'est pas rattrapée, mais bon, elle donne quand même le nom du paquet problematique, donc ça devrait être facile à retrouver et corriger.

 - EDIT ter :  petit retour sur package.unmask et package.keywords si c'était pas clair... L'utilisation combinée de ces deux fichiers doit permettre d'éviter les hacks en ligne de commande pour les paquets masqués/tildarchés. Notament, à partir d'aujourd'hui vous n'utiliserez plus de "ACCEPT_KEYWORDS=~x86 emerge foo/bar", ni de "emerge /usr/portage/foo/bar/bar.x.y.z.ebuild". Oubliez même que vous avez fait ça un jour, oubliez que ça marche, parceque ça marche mal. Voilà, je l'ai redis.Last edited by TGL on Thu Jun 17, 2004 8:51 am; edited 8 times in total

----------

## bestel

Franchement, c'est vraiment génial toutes ces nouveautés !

C'est vraiment un bon gestionnaire de package ce système....

mais...

... manque plus que les dépendances inverses que l'on nous promet depuis 2 ans  :Smile: 

ok, je sors

----------

## scout

Merci TGL pour ce beau poste explicatif. Les deux fonctionnalités là:

 *TGL wrote:*   

>  - /etc/portage/package.use :  Et non, vous ne rêvez pas, on peut maintenant activer/désactiver des USE flags pour certains paquets particuliers.
> 
>  - /etc/portage/package.keyword :  C'est LA solution pour mixer proprement du stable (arch) et de l'instable (~arch) sur votre système. 

 

Me manquaient cruellement, et vont me révolutionner la vie !!

----------

## sireyessire

Merci TGL c'est très complet et utile.

@scout: Will these features change your life as Polish opposite does ?  :Wink:   :Laughing: 

----------

## dioxmat

Il est fort ce TGL... Je savais que c'etait une bonne idée de l'avoir en modérateur :)

----------

## sebbb

J'ai une petite question en ce qui concerne portage :

Je veux installer 3 paquets : A, B, C

Portage télécharge A, compile A, télécharge B, compile B, télécharge C, compile C.

Pourquoi ne mène-t-il pas les téléchargements en paralelle ???

3 wget par exemple, pour les compilation ce n'est pas forcément possible à coause des dépendances, mais la pendant la compilation de A la connexion n'est pas utilisée, pourquoi ne pas lancer le téléchargement ??? sans lancer les 3 à la fois, mais au moins pendant les compilations, non ???

----------

## bestel

Et bien notre gentil modérateur l'a dit :

 *Quote:*   

>  Pour ceux que ça intérresse, sachez qu'on approche doucement d'un code thread safe (donc que par exemple les downloads simultanés aux compilations devraient un jour être possibles),

 

Il faut que chaque opération soit fait dans un thread séparé pour qu'il l'y ai pas de probleme. Et surtout il faut que les acces concurents aux donnés soit gérés comme il faut. Donc c'est en cours ... Et pour bientot on espere (comme les dépendances inverses pour unmerger  :Razz:   ... on espere ...  :Very Happy:  )

----------

## sebbb

Ahhhh, j'avais pas compris ça du tout moi...

Merci a toi bestel

Mais dans ce cas, est-ce qu'il peut y avoir un "risque" (de plantage) si :

- Sur une console je lance 

```
emerge world -f
```

- Sur une autre je lance 

```
emerge world
```

 (en laissant prendre un peut d'avance aux téléchargements)

----------

## kikoun

Il ne manque plus que la posibilité d'avoir plusieures sources d'arbre portage. Je m'explique:

Bin oui, on peut déjà mettre ses ebuilds perso dans /usr/local/portage, alors pourquoi ne pas avoir d'autre arbres portages que l'on pourrai mettre à jour avec un simple emerge rsync (avec peut-être une ou deux options en plus). Cela permetterais par-exemple, d'avoir des sources alternatives comme avec debian et je ne serai pas obliger de regarder tous les deux jours la derniere version d'un ebuild qui n'est pas dans portage.

Pour éviter les conflits de deux ebuilds de même version dans deux arbres différents, il pourrai y avoir un système de priorité (hop, je fais plus confiance au ebuild de l'arbre officiel donc je lui mets une priorité plus forte et bla bla bla).

Bon okay il manque aussi un systeme de dépendance inverse mais bon.

----------

## mirtouf

TGL tu a commis une faute de frappe c'est /etc/portage/package.keywords et non /etc/portage/package.keyword

Merci pour ton investissement à  rédiger cette doc !   :Wink: 

----------

## kikoun

Ha oui aussi un truc: à quand un portage qui ne travaillerai que dans un seul répertoire. Parce que là, avec l'arbre et le distfiles dans /usr/portage, son arbre dans /usr/local/portage, Monsieur qui compile dans /var/tmp/portage/ et les info sur les ebuilds installé dans /var/cache ou /var/db: c'est pas trés propres sur un serveur.

Bien sur, il y a des variables pour déplacer ces répertoires, mais ça fait beucoup de variables qui peuvent poser des problèmes.

----------

## Leander256

 *sebbb wrote:*   

> Mais dans ce cas, est-ce qu'il peut y avoir un "risque" (de plantage) si :
> 
> - Sur une console je lance 
> 
> ```
> ...

 

Puisque j'ai été assez idiot pour le faire, je peux te dire que ça marche, mais pas toujours... En fait le problème principal semble être que portage ne télécharge pas les paquets dans le même ordre (avec l'option -f bien sûr) qu'il va les compiler. Je ne sais pas si j'ai été chanceux, mais j'ai juste eu un plantage d'emerge, sans conséquences (connues?) sur le système. Mais depuis je ne me risque plus à le faire.

----------

## sebbb

Bon, ok, merci, je serai patient alors :)

----------

## gK

Petite question, j'ai mis à jour portage il n'y a pas 5 minutes.

Seulement je n'ai pas le répertoire /etc/portage ?   :Confused: 

----------

## TGL

 *kikoun wrote:*   

> Il ne manque plus que la posibilité d'avoir plusieures sources d'arbre portage. Je m'explique:
> 
> Bin oui, on peut déjà mettre ses ebuilds perso dans /usr/local/portage, alors pourquoi ne pas avoir d'autre arbres portages que l'on pourrai mettre à jour avec un simple emerge rsync (avec peut-être une ou deux options en plus).

 

En fait, la variable PORTDIR_OVERLAY accepte de multiples répertoire. Par exemple en ce moment chez moi:

```
PORTDIR_OVERLAY="/var/portage/overlays/tgl /var/portage/overlays/spyderous"
```

 Il sont prioritaires du premier au dernier, à moins que ce ne soit du dernier au premier, je sais plus faut essayer, mais ce qui est sûr c'est qu'ils sont tous prioritaires sur le répertoire officiel. C'est vrai que des overlays moins prioritaires pourrraient aussi être utile (par exemple pour faire une sauvegarde systématique des ebuilds installés).

Après, pour ce qui est de les remplir quand certains ne sont pas des overlays persos mais par exemple des mirroir des overlays de certains développeurs dispos sur le web, ça restera je pense une question de scripts externes à portage. Y'en a au moins un là mais qui ne sait faire la mise à jour que par rsync (bref il doit permettre de maintenir un overlay du genre breakmygentoo par exemple).  Y ajouter que les adresses de type http:// ou ftp:// se font par un "wget --mirror ..." ne serait pas bien difficile. Donc bon, je suppose qu'à un moment ou a un autre un tel script se retrouvera dans gentoolkit.

----------

## TGL

 *dioxmat wrote:*   

> Il est fort ce TGL... Je savais que c'etait une bonne idée de l'avoir en modérateur 

 

C'est pas l'avis de tout le monde.  :Smile:  Sur un autre forum hier, j'ai remballé un peu sêchement un mec qui braillait parceque les vilains developpeurs fesaient rien qu'à lui casser sa machine en ayant sorti cette version de portage toute bugguée, alors qu'en fait c'est juste qu'il avait une typo dans sa config, mais rien n'était cassé. Et bah il m'a envoyé chier et traité d'abruti, et que je n'avais rien d'un modérateur et tout et tout. Arf, je vous le dis moi, le forum français il rulez comparé à ceux anglais...  :Wink: 

 *mirtouf wrote:*   

> TGL tu a commis une faute de frappe c'est /etc/portage/package.keywords et non /etc/portage/package.keyword

 

Corrigé, merci. Et en plus je me souviens qu'en écrivant je me suis posé la question, je me suis dis que je vérifierai plus tard...   :Embarassed: 

 *gK wrote:*   

> Petite question, j'ai mis à jour portage il n'y a pas 5 minutes.
> 
> Seulement je n'ai pas le répertoire /etc/portage ?  

 

Ouais, il a été plus ou moins décidé de ne pas fournir de fichiers d'exemple pour les trucs de /etc/portage, juste la doc dans la page de manuel. Donc me pas un répertoire vide. J'ai pas trop compris si c'était de la flemme ou si il y avait une raison. Mais bref c'est pas grave, tu peux faire ce répertoire toi même, et tu y crées juste les fichiers dont tu as besoins, avec le manuel sous les yeux.

----------

## dioxmat

 *TGL wrote:*   

>  *dioxmat wrote:*   Il est fort ce TGL... Je savais que c'etait une bonne idée de l'avoir en modérateur :) 
> 
> C'est pas l'avis de tout le monde. :) Sur un autre forum hier, j'ai remballé un peu sêchement un mec qui braillait parceque les vilains developpeurs fesaient rien qu'à lui casser sa machine en ayant sorti cette version de portage toute bugguée, alors qu'en fait c'est juste qu'il avait une typo dans sa config, mais rien n'était cassé. Et bah il m'a envoyé chier et traité d'abruti, et que je n'avais rien d'un modérateur et tout et tout. Arf, je vous le dis moi, le forum français il rulez comparé à ceux anglais... ;)
> 
> 

 

C'est le probleme, on s'ennuie a mourrir ici, personne pour gueuler ni rien... Regarde, je fais un off-topic la et chui sur que yaura personne pour me le reprocher :) (je compte sur vous les gars :)

----------

## TGL

 *dioxmat wrote:*   

> C'est le probleme, on s'ennuie a mourrir ici, personne pour gueuler ni rien... Regarde, je fais un off-topic la et chui sur que yaura personne pour me le reprocher  (je compte sur vous les gars 

 

Si tu veux je peux splitter ton post pour un topic "[Off-le-mur] Pourquoi on s'emmerde sur le forum français ?"  :Wink:  En cherchant un peu y'a même moyen de faire un sondage...   :Laughing: 

----------

## dju`

excellent post, comme toujours TGL.  :Smile: 

----------

## TGL

 *kikoun wrote:*   

> Ha oui aussi un truc: à quand un portage qui ne travaillerai que dans un seul répertoire. Parce que là, avec l'arbre et le distfiles dans /usr/portage, son arbre dans /usr/local/portage, Monsieur qui compile dans /var/tmp/portage/ et les info sur les ebuilds installé dans /var/cache ou /var/db: c'est pas trés propres sur un serveur.

 

Très vaste sujet de troll régulier sur la mailing gentoo-dev. C'est pas évident en fait avec portage de bien répartir les choses, y'a tellement de types différents de données, certaines partageables sur le réseau et d'autres spécifiques à une machine, certaines necessitant une arborescence ou l'on peut écrire et d'autre non, certaines temporaires et d'autres non, certaines éditable par l'utilisateur et d'autres non, etc. Tous ces critères devraient permettre de choisir sans ambiguité la bonne place à chaque fois dans le FHS, mais en pratique, c'est toujours une question d'interprétation. Alors tout mettre sous un même répertoire ? Bof bof, ça ne conviendra certainement pas à tout le monde, loin de là...

Mais par contre, je te confirme qu'on a pas de problème avec portage quand on bouge des répertoires dans sa config. J'utilise moi par exemple: 

```
PORTDIR=/var/portage/tree

DISTDIR=/var/portage/distfiles

PKGDIR=/var/portage/packages

PORTDIR_OVERLAY=/var/portage/overlays/tgl /var/portage/overlays/... etc.
```

Je n'ai plus rien dans /usr, et c'est mon choix.  :Smile: 

Les seuls problèmes qu'on peut rencontrer, c'est avec des scripts externes qui utilisent la valeur par défaut au lieu de celle configurée,  mais bon, ceux de gentoolkit sont en principe corrects, et pour les petits bouts de codes qu'on trouve sur les forums ou ce genre de trucs, bah c'est facile à corriger.

Restent /var/cache, /var/tmp et /var/db: le dernier est maintenant bougeable point de vu code, donc une option devrait apparaitre assez rapidement en principe, le temps je suppose de s'assurer que au moins gentoolkit est prêt. Le cache et le tmp, eux je doute qu'ils bougent, ils collent sans trop d'ambiguité au FHS, donc y'a pas vraiment de raison...

----------

## TGL

Voilà un fichier de configuration des "mirroirs tiers", c'est à dire des serveurs à utiliser en priorité pour les adresses de type mirror://something/...

Il devrait être +/- correct pour la France, mais n'hésitez pas à me signaler toute amélioration possible. C'est un premier jet, c'est forcement améliorable.

/etc/portage/mirrors

```
# /etc/portage/mirrors

# gentoo: celui là n'est pas très utile, puisque GENTOO_MIRRORS est d'abord utilisé de toute façon.

gentoo      http://gentoo.inode.at http://distro.ibiblio.org/pub/linux/distributions/gentoo

# sourceforge: rien en France ? 

sourceforge   http://heanet.dl.sourceforge.net/sourceforge  http://cesnet.dl.sourceforge.net/sourceforge

# gnome:

gnome      http://fr.rpmfind.net/linux/gnome.org http://fr2.rpmfind.net/linux/gnome.org ftp://ftp.no.gnome.org/pub/GNOME

# kde: rien en France ? Bon bah UK alors...

kde      ftp://download.uk.kde.org/pub/kde

# gnu:

gnu      ftp://ftp.irisa.fr/pub/gnu ftp://ftp.medasys-digital-systems.fr/pub/gnu ftp://ftp.cs.univ-paris8.fr/mirrors/ftp.gnu.org 

# kernel:

kernel      http://www.fr.kernel.org/pub http://www.de.kernel.org/pub

# openoffice:

openoffice   http://ftp.club-internet.fr/pub/OpenOffice ftp://openoffice.cict.fr/openoffice

# xfree:

xfree      ftp://ftp.lami.univ-evry.fr/XFree86 http://ftp.doc.cs.univ-paris8.fr/pub/XFree86 http://ftp.belnet.be/mirror/ftp.xfree86.org
```

Ça se voit peut être pas bien, mais à chaque fois c'est une seule ligne par type de mirroir.

----------

## kikoun

TGL: merci pour tes réponses.

Personnellement, j'ai aussi déplacé tous mes répertoires dans /var qui est une partition plus adaptés aux variations.

Quand au portage overlay, je ne savais pas que l'on pouvais y mettre plusieurs répertoires.

pour conclure remerci de tes réponses claires.

----------

## yoyo

 *bestel wrote:*   

> C'est vraiment un bon gestionnaire de package ce système....

 

Que dire dans ce cas des modos ...

Merci pour ces explications et le fichier "mirrors" : il manque juste une ligne pour fluxbox ...   :Laughing: 

Il va falloir changer nos vieilles habitudes de ligne de commande (ACCEPT_KEYWORDS etc.) ... ça va pas être simple   :Confused:   :Very Happy: 

----------

## Garko

Moi, se que je trouve foi, s'est qu'il y a à peine 2-3 semaines j'ai installé une Gentoo sur mon portable. Si mon frixe j'était en KDE-3.2_rc1 et je voulais faire pareil sur mon portable... mais avec ACCEPT_KEYWORDS sa me mettait toutes les dépendances en ~x86... J'ai donc bidouiller en allan modifier les ebuild de kde.

J'ai bien pesté puis rêver de pouvoir, avec portage, sélectionner les package que je voulais en ~x86.... Et portage le fait 2 semaines plus tard  :Smile:  si la vie n'est pas belle  :Smile: 

En tout cas une chose est certaine, je ne vais avoir aucun mal à ne plus jouer avec le ACCEPT_KEYWORDS en ligne de commande puisque j'avais une sainte horreur de ça. Après je ne parle pas des autres nouvelles options, elles sont toutes aussi bien les unes que les autres  :Very Happy: ... a l'expetion de la "protection des modules" qui est la bienvenue... ne plus pouvoir utiliser mon anciens noyau lorsque j'en compile un nouveau pasque j'ai une carte nvidia... sa avais le don de m'empècher d'en tester d'autres à l'expetion de celui que j'utilise courament...

Que du bon en résumé  :Smile: 

----------

## djmanu

Moi je dis: 

A quand un portage ou on passerai l'option --binary et quand je ferai emerge --binary kde, il irai pomper le DERNIER kde + les dépendance sur le net (pas sur le cd!) en binaire ...

(et je ne parlez pas des binaires du cd SVP!).

----------

## bestel

 *djmanu wrote:*   

> Moi je dis: 
> 
> A quand un portage ou on passerai l'option --binary et quand je ferai emerge --binary kde, il irai pomper le DERNIER kde + les dépendance sur le net (pas sur le cd!) en binaire ...
> 
> (et je ne parlez pas des binaires du cd SVP!).

 

Je ne suis pas sur que ca arrivera une option dans ce genre... Ou alors dans très très longtemps. Parce qu'en fait non seulement ca pose le probleme qu'il faut que plusieurs version précompilés existent pour chaque architecture... Et dans ce cas, les USE ne servent a rien. Donc en gros on perd toute le souplesse de la gentoo. Autant prendre une Debian dans ce cas là non ?

----------

## Mozart

Moi j'ai des p'tites questions concernant cet excellent topic.

Je suis nouveau sous Gentoo et je viens de me faire une install stage 1 qui marchouille pas mal, avec kde 3.2 par exemple. Mais bêtement  :Embarassed:   j'ai lancé l'emerge de kde avec la commande:

```
emerge -k kde-3.2.ebuild
```

Ou qqch du genre (j'ai pas la machine sous la main pr vérifier). Que dois-je modifier pour réparer cette erreur et tout remettre dans le droit ordre (comme si j'avais fait un emerge -k kde).

Merci!     :Wink: 

----------

## TGL

 *Mozart wrote:*   

> 
> 
> ```
> emerge -k kde-3.2.ebuild
> ```
> ...

 

C'est pas forcement dramatique non plus. Là en l'occurence je pense pas que ce soit un problème, cet ebuild ne fait rien sinon dépendre d'autres qui eux seront installés normallement. Pour être bien sûr, essaye: 

```
% emerge -p kde
```

Il ne devrait te proposer seulement kde-base/kde-3.2, vu que les dépendances sont maintenant installées. Dans ce cas, tu peux refaire un 

```
% emerge kde
```

 et là tu seras sûr que tu es bon (ça prend pas de temps, c'est un ebuild bidon).

----------

## TGL

 *bestel wrote:*   

> Je ne suis pas sur que ca arrivera une option dans ce genre... Ou alors dans très très longtemps. Parce qu'en fait non seulement ca pose le probleme qu'il faut que plusieurs version précompilés existent pour chaque architecture... Et dans ce cas, les USE ne servent a rien. Donc en gros on perd toute le souplesse de la gentoo. Autant prendre une Debian dans ce cas là non ?

 

Bah perso je m'en suis jamais servi, mais y'a quand même les paquet GRP qui existent. Pour certains trucs genre KDE, ça peut valoir le coup, y'a pas forcement tant de USE flags que ça en jeu, et les sacrifier pour gagner beaucoup de temps peut être une bonne option pour certain. Bon par contre je suis pas sûr qu'il y ait toujours des paquets GRP pour la dernière version toute fraîche d'un paquet, comme je le disais, je m'en sers pas donc je connais pas. 

Pour plus d'info, voir la variable PORTAGE_BINHOST dans make.conf (ou dans make.conf.example si elle n'y est pas), et l'option "-g" de emerge (emerge --help et man emerge pour les détails).

----------

## j_c_p

J'ai eu un moment de doute en vous voyant ts écrire /etc/portage, mais en vérifiant, c'est bien /usr/portage ds le 2.0.50.

Voilà, sinon, j'apprécie bcp le fait de pouvoir mixer proprement le stable et l'instable désormais.

----------

## TGL

 *j_c_p wrote:*   

> J'ai eu un moment de doute en vous voyant ts écrire /etc/portage, mais en vérifiant, c'est bien /usr/portage ds le 2.0.50.

  Non.

 - /usr/portage est le répertoire mis à jour à chaque "emerge sync". Si tu bidouilles ta config là dedans (dans /usr/portage/profile/ d'ailleurs en fait), tu perdras tout à la mise à jour suivante. Celui là, on ne devrais jamais y toucher, il appartient aux développeurs Gentoo, tu n'as aucun contrôle dessus.

 - /etc/portage est le répertoire pour, sur ton système, t'écarter de ce qui est configuré dans ton profile. Ce répértoire n'existe pas tant que tu ne l'as pas créé, mais c'est bien de lui qu'on parlait ici. 

Je te suggère un petit : 

```
% man portage
```

----------

## j_c_p

Merci de la précision, je vais regarder cela en détails.

----------

## equi-NoX

 *bestel wrote:*   

> Je ne suis pas sur que ca arrivera une option dans ce genre... Ou alors dans très très longtemps. Parce qu'en fait non seulement ca pose le probleme qu'il faut que plusieurs version précompilés existent pour chaque architecture... Et dans ce cas, les USE ne servent a rien. Donc en gros on perd toute le souplesse de la gentoo. Autant prendre une Debian dans ce cas là non ?

 

vu le temps que l'on doit attendre sous Debian pour avoir quoique ce soit de nouveau (comme kde3.2 par exemple  :Confused:  ), ça serait pas si mal que ça des binaires made by Gentoo   :Smile: 

mais bon moi je préfère compiler de toutes façons  :Very Happy: 

----------

## nuts

j ai aps tout lu mais je flippe un coup. je n ai pas de /etc/portage

----------

## yoyo

 *nuts wrote:*   

> j ai aps tout lu mais je flippe un coup. je n ai pas de /etc/portage

 

Et bien dans ce cas, lis tout ...   :Razz: 

 *TGL wrote:*   

>  *gK wrote:*   Petite question, j'ai mis à jour portage il n'y a pas 5 minutes.
> 
> Seulement je n'ai pas le répertoire /etc/portage ?   
> 
> Ouais, il a été plus ou moins décidé de ne pas fournir de fichiers d'exemple pour les trucs de /etc/portage, juste la doc dans la page de manuel. Donc me pas un répertoire vide. J'ai pas trop compris si c'était de la flemme ou si il y avait une raison. Mais bref c'est pas grave, tu peux faire ce répertoire toi même, et tu y crées juste les fichiers dont tu as besoins, avec le manuel sous les yeux.

 

----------

## dyurne

c'est un super post, comme on aimerai en voir plus souvent.clair, concis, parfait pour quelqu'un qui ne lit jamais les news.

----------

## dju`

tiens TGL, vu que t'en parlais, je voulais ton avis la dessus, et celui des autres aussi bien entendu: est-ce conseillé de de faire un ebuild /usr/portage/foo/bar/bar-x.y.z.ebuild truc ou est-ce que ca peut se comporter aussi mal que de faire un emerge /usr/portage/foo/bar/bar-x.y.z.ebuild ?

le problème est que si tu dois faire une mise à jour d'un service en train de tourner, disons apache, et que tu veux minimiser le temps d'interruption de service, moi j'utilisais:

```
ebuild /usr/portage/foo/bar/bar-x.y.z.ebuild install

/etc/init.d/bar stop

ebuild /usr/portage/foo/bar/bar-x.y.z.ebuild qmerge

/etc/init.d/bar start

```

pour pouvoir compiler la nouvelle version d'apache (par exemple) tout en laissant l'ancien apache actif, ET être certain d'utiliser le bon rc-script pour arreter le service. parce que oui, une nouvelle version peut aussi remplacer le rc-script et ca peut compromettre le bon fonctionnement de l'ancien apache si tu l'arretes avec le rc-script du nouveau. des solutions pour ca?

merci  :Smile: 

----------

## yoyo

Il me semble que portage n'écrase aucun fichier contenu dans "/etc" mais qu'il mets les nouveau fichiers sous la forme "._cfg????_*" (donc "._cfg0000_bar" dans ton exemple).

Donc, tu dois pouvoir arrêter ton sevice avant l'etc-update et le re-démarrer après ... ("emerge --help config" pour plus d'info sur la variable

CONFIG_PROTECT_MASK notamment)

Sinon, une autre méthode serait :

"emerge -B bar" => compilation du paquet sans installation

"/etc/init.d/bar stop" => arrêt du service

"emerge -K bar" => installation du nouveau build et désinstallation de l'ancien

"etc-update" => mise à jour des fichiers de config ...

"/etc/init.d/bar start" => démarrage du service

Cette méthode reste assez proche de la tienne mais elle permet de gérer les paquets avec "packages.unmask", "packages.mask" et "packages.keyword" (donc de profiter des nouvelles features de portage).

----------

## bestel

C'est bizarre ce que tu dis sur les rc-script. Je pense que les scripts dont tu parles sont ceux qui permette d'executer et d'arreter les services dans /etc/init.d

Vu que ces scripts sont dans /etc normalement ils ne sont pas ecrasé avec un emerge. Pour les remplacer il faut faire un etc-update.

Donc tu peux tres bien faire un emerge -u apache... Pis /etc/init.d/apache2 stop ... puis un etc-update qui te mettra le bon script d'init pour ta nouvelle version

pendant que tu emerge un programme il ne te désemerge pas l'ancien jusqu'a ce que la compilation soit finit

----------

## bestel

oups désolé, c'est un rapide ce yoyo  :Smile: 

----------

## dju`

oui c'est vrai, je pensais plus aux ._cfg* ... bon ok pour les rc-scripts, mais on peut aussi avoir le cas d'un fichier remplacé, ou disparu, en dehors du CONFIG_PROTECT, et qui sera appelé par le old rc-script. donc dans le cas où tu fais ton emerge -u apache, /etc/init.d/apache stop, etc-update, /etc/init.d/apache start, au moment du stop ca peut appeler une commande dans /usr/bin qui a disparu, d'ou l'intéret d'arreter ton service avant que portage ne merge la nouvelle version.

yoyo: ta méthode est pas mal, c'est ca que je voudrais, pouvoir utiliser /etc/portage/* plutot que bourriner direct avec un ebuild foo install/qmerge, le problème c'est que ca passe par un package. ya pas vraiment d'intéret a faire un package pour l'installer tout de suite apres, et ensuite supprimer le package. il faudrait que portage laisse la nouvelle version dans /var/tmp/portage et qu'on puisse la reprendre pour la merger ensuite, mais sans passer par ebuild qui est trop bas niveau à mon avis, et qui n'utilise pas /etc/portage/*.

----------

## yoyo

 *dJu` wrote:*   

> ya pas vraiment d'intéret a faire un package pour l'installer tout de suite apres, et ensuite supprimer le package.

 Ben si, arrêter un service avant de le mettre à jour ...   :Wink: 

C'est ce que j'ai fait pour mettre à jour mon xfree par exemple (utilisation de ma gentoo comme poste de travail donc X tourne en permanence ou presque).

Sinon, je ne vois pas d'autre méthode à part celle que tu utilises déja. Mais je pense que tu peux quand même forcer l'arrêt d'un service (avec l'argument "zap") même s'il manque une commande ...

De plus, AMHA, les dev font attention à ne pas supprimer des pgms appelés par le service mis à jour (ou ils font en sorte qu'au moins l'arrêt de ce service reste compatible avec la nouvelle version).

Désolé de ne pouvoir dire mieux ...

----------

## CryoGen

Je sais pas si c'est possible mais je voudrai passer tout une branche de l'arbre en ~x86 comme par exemple xfce-base

Une solution ? ou alors il faut lister tout ebuild :/ ?

----------

## TGL

 *CryoGen wrote:*   

> Je sais pas si c'est possible mais je voudrai passer tout une branche de l'arbre en ~x86 comme par exemple xfce-base
> 
> Une solution ? ou alors il faut lister tout ebuild :/ ?

 

Y'a pas de joker, les entrées du fichier sont des atomes de dépendances, bref ils ne parlent que d'un seul paquet. Donc oui il faut lister. Bon maintenant, rien ne t'oblige à le faire à la main pour autant, tu as ton shell pour ça : ça prendrait 5 minutes de faire un petit script qui rafraichirait le fichier après chaque rsync pour y ajouter tous les nouveaux paquet d'une catégorie. Mais c'est vrai que qqch de plus expressif que des atomes de dépendances, permettant de parler par exemple de "xfce-base/*" serait plus pratique. Tu peux toujours un bug report pour suggerer ça.

----------

## zdra

Perso je comprends pas pourquoi on peut toujours pas faire de 

```
emerge gdesklets*
```

c'est la derniere feacture de portage que j'attends, qd ce sera fait on poura dire que portage est la 8eme merveille du monde  :Very Happy: 

----------

## TGL

 *zdra wrote:*   

> 
> 
> ```
> emerge gdesklets*
> ```
> ...

 

Bash est ton ami. Tu peux essayer un truc de ce style, dans ton ~/.bashrc : 

```
8eme_merveille() {

   local PORTDIR=$(sed -n s:^PORTDIR=::p /etc/make.conf)

   PORTDIR=${PORTDIR:-/usr/portage}

   local arg

   local targets

   local options

   for arg in "$@" ; do

      case "${arg}" in 

         -*) options="${options} ${arg}" ;;

         */*) targets="${targets} $(find ${PORTDIR}  -mindepth 2 -maxdepth 2 -type d -path "${PORTDIR}/${arg}" | sed s:${PORTDIR}/::)" ;;

         *) targets="${targets} $(find ${PORTDIR} -mindepth 2 -maxdepth 2 -type d -name "${arg}" | sed s:${PORTDIR}/::)" ;;

      esac

   done

   #echo "options: ${options}"

   #echo "targets: ${targets}"

   emerge ${options} ${targets}

}
```

 (bon c'est du vite fait hein, faut pas être trop regardant...)

Après : 

```
% 8eme_merveille -p desklet*

 

These are the packages that I would merge, in order:

 

Calculating dependencies ...done!

[blocks B     ] x11-plugins/desklet-diskinfo (from pkg x11-plugins/desklet-psisensors-20031028)

[blocks B     ] x11-plugins/desklet-networkinfo (from pkg x11-plugins/desklet-psisensors-20031028)

[blocks B     ] x11-plugins/desklet-cpuinfo (from pkg x11-plugins/desklet-psisensors-20031028)

[blocks B     ] x11-plugins/desklet-meminfo (from pkg x11-plugins/desklet-psisensors-20031028)

[ebuild   R   ] x11-plugins/desklet-clock-0.32-r1

[ebuild  N    ] dev-python/pyxmms-2.02

[ebuild  N    ] x11-plugins/desklet-cornerxmms-0.0.5-r1

[ebuild   R   ] x11-plugins/desklet-cpuinfo-0.1.4-r1

[ebuild   R   ] x11-plugins/desklet-diskinfo-0.1.4-r1

[ebuild   R   ] x11-plugins/desklet-ltvariations-0.21-r1

[ebuild   R   ] x11-plugins/desklet-meminfo-0.1.4-r1

[ebuild   R   ] x11-plugins/desklet-networkinfo-0.1.4-r1

[ebuild   R   ] x11-plugins/desklet-starterbar-0.22.1

[ebuild   R   ] x11-plugins/desklet-sysinfo-0.25

[ebuild   R   ] x11-plugins/desklet-weather-0.22

[ebuild  N    ] x11-plugins/desklet-temperature-0.2

[ebuild  N    ] x11-plugins/desklet-psisensors-20031028

[ebuild  N    ] x11-plugins/desklet-psidisplays-20031028

[ebuild  N    ] x11-plugins/desklet-goodweather-0.3

[ebuild  N    ] x11-plugins/desklet-multitail-0.2.2
```

Ou encore : 

```
 % 8eme_merveille -p gnome-extra/*

These are the packages that I would merge, in order:

 

Calculating dependencies ...done!

[blocks B     ] gnome-base/gnome-session (from pkg gnome-base/gnome-core-1.4.2-r1)

[blocks B     ] x11-terms/gnome-terminal (from pkg gnome-base/gnome-core-1.4.2-r1)

[blocks B     ] gnome-base/gnome-desktop (from pkg gnome-base/gnome-core-1.4.2-r1)

[ebuild   R   ] gnome-extra/acme-2.4.2-r2

[ebuild  N    ] gnome-extra/at-spi-1.3.16

[ebuild  N    ] gnome-base/gnome-core-1.4.2-r1

[ebuild  N    ] gnome-extra/battstat-2.0.13

[ebuild  N    ] gnome-extra/bonobo-conf-0.16

[ebuild   R   ] gnome-extra/bug-buddy-2.4.2

[ebuild  N    ] gnome-extra/drwright-0.17

[ebuild   R   ] gnome-extra/gal-1.99.10

[ebuild   R   ] gnome-extra/gcalctool-4.3.44

[ebuild   R   ] gnome-extra/gconf-editor-2.4.0

[ebuild   R   ] gnome-extra/gdesklets-core-0.26

[ebuild  N    ] gnome-extra/glibwww-0.2-r2

[ebuild  N    ] gnome-extra/gnobog-0.4.3

[ebuild   R   ] gnome-extra/gnome-audio-2.0.0

[ebuild  N    ] dev-db/sqlite-2.8.13

[ebuild  N    ] dev-perl/Error-0.15-r2

[ebuild  N    ] dev-perl/CORBA-ORBit-0.4.3-r4

[ebuild  N    ] gnome-extra/libgda-0.2.96-r2

[ebuild  N    ] gnome-extra/gnome-db-0.2.96

[ebuild   R   ] gnome-extra/gnome-games-2.4.2

[ebuild   R   ] gnome-extra/gnome-media-2.4.1.1

[ebuild  N    ] dev-util/guile-1.4.1

[ebuild  N    ] gnome-extra/gnome-network-1.0.2-r1

[ebuild  N    ] gnome-extra/gnome-pim-1.4.9

[ebuild  N    ] gnome-extra/gnome-swallow-1.1

[ebuild   R   ] gnome-extra/gnome-system-monitor-2.4.0

[ebuild   R   ] gnome-extra/gnome-utils-2.4.1

[ebuild  N    ] gnome-extra/gnome-vfs-extras-0.99.11

[ebuild  N    ] gnome-extra/gnome-vfs-sftp-0.1.2

[ebuild   R   ] gnome-extra/gnome2-user-docs-2.4.1

[ebuild   R   ] gnome-extra/gtkhtml-1.1.10-r1

[ebuild   R   ] gnome-extra/gtop-1.0.13-r2

[ebuild   R   ] gnome-extra/gucharmap-1.2.0

[ebuild  N    ] gnome-extra/guppi-0.40.3-r2

[ebuild  N    ] gnome-extra/gxmms-0.1.0

[ebuild  N    ] gnome-extra/hardware-monitor-0.7

[ebuild  N    ] gnome-extra/libgail-gnome-1.0.2

[ebuild  N    ] gnome-extra/libgda-1.0.3

[ebuild  N    ] gnome-extra/libgnomedb-1.0.3

[ebuild   R   ] gnome-extra/libgsf-1.8.2

[ebuild  N    ] net-libs/libsoup-1.99.26-r1

[ebuild   R   ] gnome-extra/libgtkhtml-3.0.9

[ebuild  N    ] gnome-extra/lock-keys-applet-1.0

[ebuild  N    ] gnome-extra/medusa-0.5.1-r3

[ebuild  N    ] gnome-extra/merlin-cpufire-0.1.0-r1

[ebuild   R   ] gnome-extra/nautilus-cd-burner-0.6.1

[ebuild  N    ] gnome-extra/nautilus-gtkhtml-0.3.2

[ebuild   R   ] gnome-extra/nautilus-media-0.3.3.1

[ebuild  N    ] gnome-extra/power-applet-0.2

[ebuild  N    ] gnome-extra/quick-lounge-applet-2.0.3

[ebuild  N    ] gnome-extra/shermans-aquarium-2.2.0

[ebuild  N    ] gnome-extra/users-guide-1.2-r1

[ebuild   R   ] gnome-extra/yelp-2.4.2

[ebuild   R   ] gnome-extra/zenity-1.8 
```

Enfin bref ça fait +/- ce à quoi tu t'attendais.

EDIT: corrigé une merdouille de tab/espace dans le code.

EDIT2: typos mineures.Last edited by TGL on Sun Mar 21, 2004 3:09 pm; edited 2 times in total

----------

## TGL

 *TGL wrote:*   

> Enfin bref ça fait +/- ce à quoi tu t'attendais.

  Ouaif, premier bug auquel je pense, ça ne prend pas en compte des paquets qui n'existeraient que dans tes overlays. 

Je laisse sa correction en exercice.   :Twisted Evil: 

----------

## zdra

mouai... faudrait que je m'y mettre plus sérieusement à batch pcq là jpige rien...

en tout cas merci, jv me trouver un tuto et étudier ça  :Very Happy: 

----------

## TGL

 *zdra wrote:*   

> mouai... faudrait que je m'y mettre plus sérieusement à batch pcq là jpige rien...

  Oh le vilain lapsus  :Razz: 

 *zdra wrote:*   

> en tout cas merci, jv me trouver un tuto et étudier ça 

  Sans la moindre hésitation, je te conseille un petit 

```
# emerge abs-guide
```

 et puis tu vas faire un tour du côté de /usr/share/doc/abs-guide-2.5/HTML/index.html

----------

## Zentoo

Thread très interessant !   :Smile: 

```
 man revdep-rebuild 
```

 ==> c pas ca les dépendances inverses ?

```
emerge esearch
```

 ==> esync & esearch a la place de emerge sync et respectivement emerge -s/S

   Ca sppede vraiment cette fois les recherches... et le sync t'affiche le nouveautées masquées ou pas et celles qui te concernent a updater   :Cool: 

   Pour les features, moi j'aimerais bien une option de comparaison MD5 des synchronisations de portage sur plusieurs mirroirs pour une question de sécurité.

TuTTle

----------

## piecq

 *Tuttle wrote:*   

> 
> 
>    Ca sppede vraiment cette fois les recherches... et le sync t'affiche le nouveautées masquées ou pas et celles qui te concernent a updater  
> 
> 

 

oué mais il ne faut pas faire une update de la base de donnée avec eupdatedb a chaque synchronisation? ce qui plombe bien sur netement les performances de esearch!  :Smile: 

----------

## dioxmat

Tu fais plus souvent un sync que une recherche toi ? :)

Sinon, esync appelle eupdatedb automatiquement...

----------

## piecq

non!  :Smile:  vu qu en plus derriere un proxy, en plus sa peut pas marché car moi je fait un emerge-webrsync!  :Wink: 

----------

## haceye

salut,

attende le prochaine version de esearch, il soutiendra esync.

(excuse mon français)

David

----------

## cdannemark

 *CryoGen wrote:*   

> Je sais pas si c'est possible mais je voudrai passer tout une branche de l'arbre en ~x86 comme par exemple xfce-base
> 
> Une solution ? ou alors il faut lister tout ebuild :/ ?

 

Perso, j'ai fais appel à sed pour m'aider à lister tous les paquets à mettre dans mon /etc/portage/package.keywords : 

```
ACCEPT_KEYWORDS="~x86" emerge -pv /usr/portage/gnome-base/gnome/gnome-2.6.ebuild | sed -e "s/\[ebuild[^]]*\] \([^ ]*\) .*/=\1 ~x86/"
```

Ca me donne un truc dans le genre : 

```
These are the packages that I would merge, in order:

Calculating dependencies  ...done!

=x11-libs/libwnck-2.6.0.1 ~x86

=gnome-base/libgtop-2.5.2 ~x86

=dev-libs/glib-2.4.0 ~x86

...

=gnome-extra/gnome2-user-docs-2.6.0.1 ~x86

=dev-libs/atk-1.6.0 ~x86

=gnome-base/gnome-2.6 ~x86

Total size of downloads: 113,567 kB

```

Suffit d'enlever les lignes en trop qui se trouvent au dessus et en dessous, de mettre le résultat dans /etc/portage/package.keywords et hop ! Petite (  :Smile:  ) mise à jour de mon système qui ne se rend même pas compte qu'il utilise des ~x86. J'adore ce nouveau portage...

----------

## zdra

idée pour les prochaines version de portage :

ajouter la possibilitée de faire une pause/résume de l'émerge !

fin je sais pas si c possiblé, voire déjà possible  :Very Happy: 

----------

## Thom N2h

si tu fais ctrl+c puis que tu reprends le emerge avec --resume ça marche, mais ça reprend packages par packages il me semble

----------

## zdra

oui reprendre package par package c'est bien mais pas suffisant... moi ce que j'aimerais en fait c'est pouvoir lancer la compilation de openoffice un soir, me lever la matin, remarque que c'est pas fini et mettre pause pour avoir un pc utilisable, puis relancer le soir pour finir la compilation...  :Very Happy: 

----------

## Thom N2h

ds /etc/make.conf en attendant

PORTAGE_NICENESS=10

----------

## Leander256

 *zdra wrote:*   

> oui reprendre package par package c'est bien mais pas suffisant... moi ce que j'aimerais en fait c'est pouvoir lancer la compilation de openoffice un soir, me lever la matin, remarque que c'est pas fini et mettre pause pour avoir un pc utilisable, puis relancer le soir pour finir la compilation... 

 

Pour faire ça tu peux le mettre en arrière-plan dans la console avec CTRL+Z. Ensuite pour le récupérer tape:

```
jobs
```

qui va te donner une liste des travaux mis en attente de la sorte avec un numéro les identifiant, et fais (je mets 1 parce que souvent on a juste un travail en pause donc son numéro c'est 1):

```
fg 1
```

Bien sûr ce n'est pas parfait, par exemple la mémoire utilisée par emerge (et gcc, etc...) n'est pas libérée, mais ça libère le processeur.

----------

## zdra

merci, encore un ptit truc que je connaissais pas  :Smile: 

----------

## dyurne

une idée (bonne ou mauvaise, à voir) pour une prochaine version de portage : 

faire du prelink, une variable USE.

par exemple si on fait "emerge -pv openoffice" on pourrait voir prelink dans les variables. après la compilation portage appliquerait automatiquement prelink à tous les binaires issus de l'emerge.

----------

## ghoti

Tiens, il semblerait que /etc/portage/package.unmask ait priorité sur /etc/portage/package.mask

En fait, j'ai constaté ça suite à une erreur de ma part : il y a un certain temps, j'avais "unmasqué" xfree-4.3.0-r6 pour ma tablette graphique et aujourd'hui, suite à l'installation de xorg, j'ai voulu masquer tous les xfree pour vérifier qu'aucun package n'essairerait de le réinstaller, en oubliant bien sûr ma précédente entrée.

Et justement, gambas n'a pas encore été corrigé (c'est imminent).

Du coup, un emerge -uUD world un peu rapide m'aurait foutu le bazard ... 

Je ne sais pas si l'ordre des priorités est mentionné quelque part (j'ai pas cherché des heures, non plus  :Wink:  ...)

A toutes fins utiles ...

----------

## zdra

C'est vrai que part mesure de sécurité il serait préférable d'avoir.mask qui prime sur .unmask  :Wink:  Avis aux developpeurs....

----------

## kernelsensei

je me pose une question :

"Y a t il moyen de parametrer l'option buildpkg (qu'on peut trouver dans le make.conf FEATURES=) par paquet ?"

par exemple, je veux faire un build systematique de certains paquets seulements (gcc, glibc, ...) et emerger les autres normalement ...

----------

## guilc

Y a déja "buildsyspkg", qui englobe gcc/glibc, etc et est plus restreint que buildpkg..

----------

## TGL

Allez hop, assez vu, je déstickyse. Et puis pour ceux qui n'aurait pas encore lu tout ça 100 fois, il pourront toujours le retrouver depuis l'annuaire de yuk.

----------

## YannTechGeek

Bonjour,

J'utilise la suite mozilla (thunderbird & firefox) mais j'aime bien l'avoir en FR donc je met le .xpi etc tout va bien (sauf quelque droit a étatablir mais rien de bien méchant), je viens donc de voir que portage peux limiter une version ou autre mais comment 'fixer' a une version spécifique ? du style firefox 0.9 et non ~x86 car cela serais 0.9.1 et non rien du tout puisqu'que ce serais la version 0.8-r3 ....

Note : mauvais exemple puisq'que FireFox Fr en version 0.9 n'éxiste pas mais passons si vous le voulez bien  :Wink: 

j'ai tenté de mettre dans /etc/portage/package.mask un 

```
 < net-www/mozilla-firefox-0.9 
```

et d'autre mais rien n'y as fait si je met pas ~x86 dans package.keywords je n'ai pas les version supérieur enfin bref je n'arrive pas a fixer la version que je veux

----------

## _droop_

Soir'

une petite question bete (bah j ai le droit non ?) : pourquoi ce thread est pas en post it ?

je l'ai un peu cherche mais bon la il vient de remonter...

----------

## YannTechGeek

tout simplement parcequ'il était stické pendant pas mal de temps .... et que portage 2.0.50 est sorti depuis un bout de temps .....

----------

## DuF

 *_droop_ wrote:*   

> Soir'
> 
> une petite question bete (bah j ai le droit non ?) : pourquoi ce thread est pas en post it ?
> 
> je l'ai un peu cherche mais bon la il vient de remonter...

 

Il est référencé dans le sticky topic qui référence tous les how-to et guide de référence gentoo, comme tu peux le constater il y en a un paquet, donc s'ils étaient tous en sticky on aurait toute la première page du forum qui ne serait que des sticky topics....

----------

