# [Portage] Passer à la branche test ou pas? (résolu)

## Kevin57

Bonjour à tous,

Je suis sous gentoo depuis quelques semaines seulement, mais pas totalement nouveau sous linux puisque j'ai passé presque un an sous Fedora, précédé d'un mois sous Kubuntu (j'ai pas aimé!). Mais le passage de Fedora à Gentoo est un peu dur : passage de KDE4 à KDE3.5, idem pour thunderbird, etc. Je ne cherche pas forcément la toute nouvelle version de chaque logiciel, mais j'aimerais pouvoir réutiliser les skins, etc. que j'avais sous Fedora, et qui ne sont pas compatibles avec ces vieilles versions (notamment thunderbird), ou alors garder les mêmes fonctionnalités, car certaines ont disparu du fait du downgrade. J'envisage donc de passer à la branche test de portage, mais avant cela j'ai quelques questions :

-C'est une branche de test, d'accord, mais est-elle tout de même assez stable? J'entends par là, les bugs sont-ils fréquents ou plutôt rares? Et plutôt vite corrigés ou non? Pour avoir utilisé plusieurs logiciels en beta sous Fedora (car dans les dépôts officiels), ils m'ont semblé plutôt stables, mais qu'en est-il de Gentoo? 

-Est-il possible d'imposer à certains paquets de rester en version stable? Le genre de logiciels qu'on n'a surtout pas envie de voir planter parce qu'on s'en sert tous les jours. J'ai cherché dans la doc mais je n'ai pas trouvé, ça a dû m'échapper.

-Puisque j'aurai certainement beaucoup de choses à recompiler (rien que OpenOffice dure des heures à lui seul alors j'ose pas imaginer le temps que ça va prendre!), j'ajoute une autre question, même si elle n'est pas en rapport direct : je crois avoir fait une erreur à l'installation de Gentoo en choisissant du 32 bit au lieu de 64, comment en être sûr? Et est-il possible de rectifier le tir, bien que j'en doute, sans tout réinstaller? (J'ai eu tellement de mal à tout faire marcher, je viens de régler les derniers problèmes, que je n'ai aucune envie de tout réinstaller maintenant!)

Voilà pour les questions, merci beaucoup d'avance. Le reste de mes interrogations a été satisfait par la documentation, comme toujours assez complète!

Kevin57

----------

## gregool

Salut,

la question est as tu vraiment besoin de tildarcher TOUT ton système ?

tu peux très bien demasquer certains paquets à l'aide de package.keywords, c'est la doc que tu cherchais

CF: http://www.gentoo.org/doc/fr/handbook/handbook-x86.xml?part=3&chap=3

et pour la migration de x86 à x86_64 tu peux toujours changer le CHOST 

CF: http://www.gentoo.org/doc/en/change-chost.xml

je ne l'ai jamais fait, j'ai prévu de changer de machine bientot et je vais repartir sur une nouvelle install, je pense que la temps de la manip plus le temps passé à corriger les problèmes pour arriver a un résultat incertain ça ne devrait pas être plus rapide qu'une install fraiche.

je ne m'y risquerais pas...

la doc commence par  *Quote:*   

> Changing the CHOST is a big issue that can seriously screw up your system

 

mais peut être que quelqu'un aura un retour d'experience à faire partager sur le sujet, parceque je parle pas en connaissance de cause

----------

## Kevin57

En effet, je n'ai pas forcément besoin de le faire pour tout, mais je pensais juste que ce serait plus simple de tout passer une fois pour toute plutôt que devoir le faire pour chaque paquet qui m'intéresse, un par un, à condition que ça soit tout de même à peu près stable.

Pour la migration à x86_64, ça m'a l'air un peu risqué et compliqué, surtout si la doc là-dessus n'est qu'en anglais, que je comprends à peu près, mais bon... Je ne vais peut-être pas me lancer là-dedans, la différence est-elle vraiment sensible entre 32 et 64 bits? J'ai eu Kubuntu en 32 bits et Fedora en 64, mais je n'ai pas souvenir d'avoir perçu de grands changements...

----------

## xaviermiller

Salut,

la migration 32 <-> 64 bits est impossible, car ce sont des architectures trop différentes.

le doc mentionné parle de i486 vers i686...

De mon côté, je suis en ~x66 / ~amd64 depuis le début.

Et bien, c'était vachement plus "rodéo" il y a quelques années, maintenant, c'est juste instable de temps en temps, et ça se restabilise assez vite (en 2-3 jours, sauf gros coups de pieds dans la fourmilière, ce qui arrive 1 fois par an, durant les vacances scolaires, on se demande pourquoi...  :Wink: )

----------

## gregool

il n'y a aucun benchmark qui montre avec certitude un gain de performance en utilisant un système en 64bits.

la vraie différence c'est la gestion de la mémoire, mais disons que si tu as un processeur qui supporte le 64Bits à quoi bon rester en 32?

aujourd'hui le choix m'est imposé par mon materiel, mais dès que je change de machine je passerai en 64 Bits, si c'est pas pour les perfs ça sera deja pour le fun et parceque j'ai prévu plus de 4Go de Ram...

----------

## xaviermiller

Salut,

Je suis passé récemment de ~amd64 en ~x86, parce que je n'ai que 2 Go et que je trouvais idiot d'avoir certaines libs en double, à cause que tout n'est pas encore porté en 64 bits (les -bin principalement).

Mon Gentoo32 semble plus réactif que le 64, je ne peux pas dire pourquoi...

----------

## Kevin57

D'après ce que vous dites, je crois bien que je vais rester en 32 bits. On verra bien plus tard, si l'envie me prend de réinstaller Gentoo, peut-être que je passerai en 64. Mais pour l'instant je n'ai pas envie de me replonger dans ces problèmes, je viens à peine de me sortir d'un mois de problèmes informatiques! Donc là j'ai eu ma dose pour un certain temps!  :Very Happy: 

 *Quote:*   

> la vraie différence c'est la gestion de la mémoire, mais disons que si tu as un processeur qui supporte le 64Bits à quoi bon rester en 32? 

 

En quoi la gestion de la mémoire est-elle différente? Et je répondrai à la question par une autre : si on pourrait être en 64 bits mais que tout marche très bien en 32, à quoi bon prendre le risque de tout changer et de tout réinstaller pour peut-être avoir plus de problèmes ensuite?

Donc il ne me reste plus que ma question sur la branche test, si certaines personnes qui l'utilisent passent par là, j'aimerais bien avoir des avis. Surtout que je passe déjà mon temps à ajouter des paquets à mon packages.keyword donc au final, je pense que ça simplifierai les choses de tout passer en test sauf une ou deux applications si je vois que la version test est trop instable, si c'est possible.

----------

## xaviermiller

Salut,

La question est : "as-tu plus, ou moins de 4 GO de RAM ?". Si tu as plus de 4 GO, passe en 64 bits, sinon, tu choisis (les  geeks préfèrent les 64 bits).

et j'ai déjà répondu concernant la branche instable  :Wink: 

----------

## Kevin57

 *Quote:*   

> La question est : "as-tu plus, ou moins de 4 GO de RAM ?". Si tu as plus de 4 GO, passe en 64 bits, sinon, tu choisis (les geeks préfèrent les 64 bits). 
> 
> 

 

Il me semble que j'ai moins de 4GO, mais là je ne suis pas chez moi donc je ne peux pas vérifier. Et comme je ne suis pas un geek, je vais rester en 32!  :Razz: 

 *Quote:*   

> et j'ai déjà répondu concernant la branche instable 

 

Oups, désolé, je n'avais pas fait attention au ~. Mais une question tout de même, est-il possible après avoir tout passé en instable, de faire revenir certains paquets en stable? J'ai cru comprendre que c'est impossible pour le système entier, mais pour juste quelques paquets?

----------

## kernelsensei

Moi j'ai toujours été en 100% ~arch (instable). Jamais eu de gros gros soucis. 99% du temps les upgrades se font comme sur des roulettes. Dans les cas compris dans le 1%, il arrive que t'en chie un peu a chercher l'origine du problème (forums, bugzilla, google), mais rien de dramatique.

EDIT : je viens de voir ton nouveau post : oui c'est possible de repasser des paquets précis en stable grâce au package.keywords (tant que cela ne pose pas de problèmes de dépendances)

----------

## Kevin57

OK ben merci beaucoup pour tous ces renseignements, je vais m'y atteler dès mon retour chez moi ce soir, en espérant que ça marche! Pour package.keywords, je n'ai pas compris comment il faut faire pour qu'il utilise la version stable? Et faut-il effacer le contenu actuel de ce fichier si je passe en instable, puisqu'il fait double-emploi, non?

----------

## kwenspc

Même avec + de 4Go on peut rester en 32bits grâce au mode PAE. 

XavierMiller: y a peu de chances qu'en 32bits ton systèmes soit plus réactif, mais ça vaut presque aussi pour le 64bits.

Par ex, pas mal de personne avancent l'argument que sur un 64bits au moins les registres généraux sont en 64bits donc pour le traitement vidéo/imagerie ce sera plus intéressant. Et bien en fait ça change pas grand chose car depuis des années les fondeurs ont inclus des instructions et registres spécifiques permettant de traiter du 64bits et même du 128 bits. (mmx, sse, 3d now!, etc...) Les logiciels ont très vite utilisés ces derniers. Encore plus sur notre Gentoo  :Wink:  grâce au CFLAGS. Bien évidemment avoir des registres généraux en 64bits est intéressant mais pas primordial. Il faut là encore que ça ait un intérêt selon l'application. (Ex concret: les système de fichiers !  XFS, par exemple se sentira TRÈS à l'aise en 64 bits, ce qui le boost pas mal)

Par contre, là où le 64bits gagne nettement sur le 32 bits c'est dans le nombre de registres généraux: 8 en 32bits, 16 en 64bits. C'est ce qui fait la petite différence au niveau des perfs.

Au final être en 64bits ne change pas drastiquement par rapport au 32bits, mais globalement on y gagne un poil tout de même. Mais il est vrai que c'est pas "notable" plus que ça pour l'utilisation de tous les jours, c'est sur certains point bien précis, via des benchs, qu'on peut apprécier cette différence.

----------

## kernelsensei

Pour la package.keywords. 

Quand tu es en stable et que tu veux installer du instable tu fais :

```
categorie/paquet ~arch
```

Quand tu as ton système en instable et que tu veux installer du stable, tu fais :

```
categorie/paquet -~arch
```

----------

## Kevin57

Merci pour tous ces renseignements, et surtout pour la rapidité des réponses, j'en suis soufflé! J'essaie tout ça ce soir et , si ça marche bien, je passe le sujet en résolu. 

Ce que dit kwenspc me confirme dans l'idée que ce n'est pas la peine de passer en x86_64, ce sera beaucoup de temps de perdu pour pas beaucoup plus de perfomances. Je le ferai à l'occasion, si j'ai besoin de réinstaller Gentoo un jour j'en profiterai.

----------

## Kevin57

En regardant mon make.conf, je viens de m'apercevoir que j'ai CHOST="i486-pc-linux-gnu", donc je ne suis même pas en i686? Là je dois peut-être au moins mettre à jour vers i686, non? Et je confirme que je n'ai que 1Go de RAM.

Ensuite, j'ai ajouté ACCEPT_KEYWORDS="~x86" dans mon make.conf. emege m'a demandé d'ajouter un certain nombre de useflags (mysql, consolekit, entre autres), mais maintenant il me sort une erreur avec des paquets bloqués, voici la liste :

```
 * Error: The above package list contains packages which cannot be

 * installed at the same time on the same system.

  ('ebuild', '/', 'sys-fs/udev-146', 'merge') pulled in by

    sys-fs/udev required by ('installed', '/', 'net-wireless/rt73-firmware-1.8', 'nomerge')

    virtual/dev-manager required by world

    >=sys-fs/udev-124 required by ('installed', '/', 'sys-fs/cryptsetup-1.0.6-r2', 'nomerge')

    (and 4 more)

  ('installed', '/', 'app-arch/lzma-utils-4.32.7', 'nomerge') pulled in by

    app-arch/lzma-utils required by ('ebuild', '/', 'dev-libs/mpfr-2.4.1_p5', 'merge')

    app-arch/lzma-utils required by ('ebuild', '/', 'media-libs/netpbm-10.46.00-r1', 'merge')

    app-arch/lzma-utils required by ('ebuild', '/', 'sys-apps/coreutils-7.5', 'merge')

    (and 5 more)

  ('installed', '/', 'net-wireless/bluez-utils-3.36', 'nomerge') pulled in by

    net-wireless/bluez-utils required by world

    >=net-wireless/bluez-utils-3.11 required by ('installed', '/', 'net-wireless/kdebluetooth-1.0_beta8-r2', 'nomerge')

  ('ebuild', '/', 'net-wireless/bluez-4.39-r2', 'merge') pulled in by

    net-wireless/bluez required by ('ebuild', '/', 'kde-base/solid-4.3.1', 'merge')

  ('ebuild', '/', 'sys-fs/device-mapper-1.02.28', 'merge') pulled in by

    >=sys-fs/device-mapper-1.00.07-r1 required by ('installed', '/', 'sys-fs/cryptsetup-1.0.6-r2', 'nomerge')

  ('ebuild', '/', 'dev-libs/boost-1.39.0', 'merge') pulled in by

    >=dev-libs/boost-1.33.1 required by ('ebuild', '/', 'app-office/openoffice-3.1.1', 'merge')

    dev-libs/boost required by ('ebuild', '/', 'app-office/akonadi-server-1.2.1', 'merge')

    dev-libs/boost required by ('ebuild', '/', 'kde-base/libkleo-4.3.1', 'merge')

    (and 5 more)

  ('ebuild', '/', 'app-arch/xz-utils-4.999.9_beta', 'merge') pulled in by

    app-arch/xz-utils required by ('ebuild', '/', 'app-arch/libarchive-2.7.1', 'merge')

    app-arch/xz-utils required by ('ebuild', '/', 'app-portage/eix-0.18.0', 'merge')

  ('installed', '/', 'net-wireless/bluez-libs-3.36', 'nomerge') pulled in by

    net-wireless/bluez-libs required by world

    net-wireless/bluez-libs required by ('installed', '/', 'dev-libs/openobex-1.5', 'nomerge')

    >=net-wireless/bluez-libs-3.11 required by ('installed', '/', 'net-wireless/kdebluetooth-1.0_beta8-r2', 'nomerge')

    (and 4 more)
```

Si j'ai bien compris, il s'agit de paquets donc la présence empêche l'installation de nouveaux paquets, mais je n'arrive pas à comprendre le détail de chaque erreur, en gros lequel bloque lequel, et donc lequel doit être enlevé. J'espère que vous pourrez m'aider.

----------

## xaviermiller

Salut,

De quel stage es-tu parti ? On dirait que tu as choisi un tout vieux "stage1"...

----------

## Leander256

 *Kevin57 wrote:*   

> -Puisque j'aurai certainement beaucoup de choses à recompiler (rien que OpenOffice dure des heures à lui seul alors j'ose pas imaginer le temps que ça va prendre!)

 

Juste une petite précision au sujet d'OOo, il y a un paquet binaire disponible qui s'appelle app-office/openoffice-bin. Il n'y a pas la possibilité de le paramétrer aussi finement que la version source bien sûr, mais du moment qu'il fait le boulot qu'on lui demande...

----------

## Kevin57

XavierMiller : a priori je suis parti d'un stage3, j'ai suivi pas à pas la documentation. Mais un uname -a m'indique bien i686:

```
uname -a

Linux Kevin 2.6.30-gentoo-r6 #2 SMP Thu Sep 17 00:04:14 CEST 2009 i686 Intel(R) Core(TM)2 CPU 4400 @ 2.00GHz GenuineIntel GNU/Linux
```

Mais au fait, qu'est-ce qui te fait poser cette question? Les paquets installés ou autre chose?

Leander256 : openoffice-bin serait plus rapide à installer?

----------

## Pixys

 *Kevin57 wrote:*   

> openoffice-bin serait plus rapide à installer?

 

Carrément puisqu'il n'y a pas à le compiler (c'est un binaire qui a été compilé pour toi)

----------

## Kevin57

Ah ok, je ne savais pas! Merci du conseil, je vais faire ça alors parce que passer 3h à compiler OpenOffice merci bien!  :Very Happy: 

----------

## xaviermiller

Bon, change de CHOST, en suivant bien la doc : http://www.gentoo.org/doc/fr/change-chost.xml

Un CHOST = i486, ça sent le trèèès vieux Gentoo ça, ou un vieux stage1.

Quel stage 3 précisément ? Ne prends pas un "x86" qui est en fait un i486, mais prends un "pentium4" par exemple.

----------

## Kevin57

Ah ben j'avais dû prendre un x86, d'où l'erreur. Je vais donc changer mon CHOST, pour la branche test on verra après!

----------

