# [DOW] Gentoo Stable VS Gentoo Unstable

## anigel

Et voici, en totale exclusivité intersidérale, notre premier débat officiel.

Vous utilisez Gentoo en stable ? Vous êtes un aventurier, et vous êtes en full unstable ? Vous faites un mix plus ou moins éclairé des deux ? On veut tout savoir : pourquoi ? Comment ? Quelles astuces utilisez-vous pour gérer vos packages ? Comment faire face aux problèmes de la version unstable ? Et tout ce à quoi on n'ai pas pensé !

3, 2, 1 : action !

----------

## Trevoke

La seule raison que je vois de garder le systeme en stable c'est que parfois, un package a des modifications qui sont faites pour le rendre stable mais il ne change pas de version, donc si on est en instable on n'a pas la meilleure version (meme is le package est stable). Pour ca, il est donc preferable d'utiliser /etc/portage/package.keywords...

Ceci dit, on devient vite coince quand on a envie d'essayer quelque chose de nouveau! En stable, on est garanti que ca marche (a condition de lire le mode d'emploi, hein, faut etre bete mais pas con), mais on peut aussi se retrouver largue si on ne fait pas gaffe.

Je suis en instable et je ne le regrette pas. En faisant un peu joujou, j'ai essaye le nouveau GCC et le nouveau PORTAGE.. Je decouvre ce que les devs nous preparent et mon cerveau reste alerte, donc je suis plus a-meme d'aider les gens. De plus, je fais partie des premiers a voir les changements, qui parfois sont super-mega-top-cools et mettent quelques mois a arriver en stable...

[edit: je suis en instable sur mon ~x86, ~amd64 et ~alpha ! ]

----------

## guilc

Bon, ben sans troller (raté  :Wink: ) je vais tenter de donner mon avis sur les deux :

- Stable : A priori mieux pour le débutant, car théoriquement plus éprouvé, je dis bien théoriquement. J'ai en effet relevé certains problèmes :

-> certains paquets ont (par erreur) des dépendances en unstable, conduisant a des boucles d'upgrade/downgrade (cf ivman récemment, mais ce n'est pas un cas isolé).

-> Certains paquets mettent parfois du temps a arriver en stable, ça peut etre frustrant pour les maniaques de la mise a jour (comme moi :mrgreeen:)

-> Les paquets subissant des failles sécurité sont en général plus vites présent en unstable qu'en stable (ils sont en instable dès le début du process de correction de la faille sécu, et certaines herds mettent du temps a les stabiliser suivant les architectures). Certes, quand la GLSA parait, ils sont en stable sur toutes les archis, mais la GLSA parait parfois plusieurs jours/semaines après la sortie de la faille...

- Unstable : bien sur pas mal plus a jour, mais :

-> Parfois des problèmes plus ou moins graves (exemple, le baselayout daubé sur les pré-versions).

-> On essuie les platres des nouveaux ebuilds, pas hyper testés. En général, y a pas de problèmes (encore plus maintenant qu'il y a quelques années, la situation s'est bien améliorée), mais on n'est pas completement a l'abri (ça sert aussi l'instable !)

Bref, j'aurais tendance a conseiller l'instable, A CONDITION d'être un minimum prudent. par exemple masquer les _pre de baselayout/portage. et TOUJOURS agir avec précautions, ne JAMAIS se précipiter. En effet, au bilan, je trouve que l'instable n'est pas plus génératrice de problèmes que la stable. Je précise, je tourne en instable depuis mes débuts sous Gentoo (ça doit faire 3 ou 4 ans maintenant). Avec un peu plus de réticences pour les noobs, mais avec un minimum d'assistance, je pense qu'il peuvent très bien gérer ça.

Et puis, j'insiste sur le fait que Gentoo a besoin de gens sur l'instable, sinon, la stable n'avancerait jamais faute de manque de remontées de problèmes  :Wink: 

Mes 2 cents a ce troll qui a mon avis n'en est pas un   :Wink: 

----------

## _droop_

Le meilleur c'est de mélanger :

```
cat /etc/portage/package.keywords | wc -l

187
```

```
emerge -a depclean

Packages installed:   395

Packages in world:    55

Packages in system:   59

Unique package names: 395

Required packages:    402

Number removed:       0
```

Je suis en 1/2 ~x86.

Pourquoi être en stable : 

- ne pas tester les nouveau baselayout qui boot pas (c'est pas gentil de ma part de le dire comme ça)

- ne pas mettre à jour trop souvent les même paquets pour des changements plus ou moins cosmétiques (la compilation c'est pas bon pour l'environnement   :Embarassed:  )

- ne pas être le premier à découvrir un bug (comment ça, je suis un planqué !?)

Pourquoi être en instable :

- tester(et adopter) le nouveau xorg et ses drivers ati open source (c même plus ~x86 là vu que c'est encore masqué).

- utiliser konqueror avec des filtres adblock (sous entendu, utilisé kde-3.5.1 qui est stable et ajoute quelques nouvelles fonctionnalités sympathiques).

- utiliser le nouveau portage qui fait le emerge --metadata (Updating portage cache pour ceux qui verraient pas) beaucoup plus vite que l'ancien.

Voilà.

----------

## Enlight

Pour ma part, je dirais instable si on a du temps... en x86 les choses marchent normalement "out of the box", donc si on a un gros projêt et qu'on veut que les choses marchent simplement je dirais d'adopter un profile stable.

Par contre si on a un peu de temps, le ~ c'est le pied total, on a le sentiment d'être un pioneer, et avec un peu de chance (oui de la chance) on pète quelque chose, et la le challenge commence, faut s'informer, essayer de comprendre etc... jusqu'a pouvoir fixer le problème, et ça c'est vraiment plaisant. Je crois que si j'avais pas autant fait le cake avec ma gentoo au cours de l'année passée (<3615 my_life>elle a eu son anniv en janvier juste avant le décès dela mobo</3615>) je ne me serais jamais posé certaines questions... alors finalement je vais dire...

ACCEPT_KEYWORDS="-*"  :Mr. Green:  et bon apprentissage!

ps : anigel je te propose une transition vers le prochain T.O. : mettre souvent à jour ma gentoo risque-t'il de fragmenter mon file system  :Laughing: 

----------

## Trevoke

Enlight, ouais bon, on s'en rappelle tous de ta mobo  :Smile: 

----------

## Enlight

 *Trevoke wrote:*   

> Enlight, ouais bon, on s'en rappelle tous de ta mobo 

 

et ouais => https://forums.gentoo.org/viewtopic-p-3042822-highlight-.html#3042822  :Crying or Very sad: 

----------

## nanotux

Personnelement je suis en stable mais j'ai quand même ACCEPT_KEYWORDS="~x86".

Pour moi le unstable doit être très intéressant pour quelqu'un qui veux tester les nouveautés ou qui veux participé au devellopement en essuyant les platres (comme le dit guilc). Mais par contre je pense qu'il faut quand même avoir de bonnes connaissances peut être plus de temps à y consacrer.

Pour moi le stable est très bien pour quelqu'un qui se lance dans l'aventure mais c'est vrai qu'on peut être bloqué par certain paquets masqué qu'on ne peut pas installé.

Donc pour ma part je rejoint Enlight sur ACCEPT_KEYWORDS=" "   :Wink: 

----------

## guilc

 *nanotux wrote:*   

> Personnelement je suis en stable mais j'ai quand même ACCEPT_KEYWORDS="~x86".

 

On appelle ça l'instable   :Laughing: 

----------

## nico_calais

Moi je suis en stable. J'ai été tenté une fois de prendre un package en instable car il n'y avait pas encore de version stable. J'ai vite compris pourquoi il etait pas en stable...

----------

## loopx

serveur => stable (car pas envie de résoudre des problèmes du style downgrade, etc...)

portable ou pc => instable (pour profiter des derniers ebuild après emerge sync  :Wink:  )

----------

## nemo13

Bon globalement :

il n'y a pour le moment que des gens pas assez prudent pour les stables  :Sad: 

et des petits joueurs  :Cool:   pour l'instable   :Shocked:  sisi  :Shocked: 

dévelloppement :

Pour le stable : 

```
prendre une gentoo stage 3 x386

si l'interface chaise / clavier n'est pas  ( trop ) buggée çà démmarre tout seul.

faire que de la console et les rares fois qu'il est nécessaire d'oser aller sur le webe

utiliser link -g

et puisque la machine ronronne, ne jamais plus la mettre à jour.
```

Pour les geek instables :

bof avoir ACCEPT_KEYWORDS="~x86" c'est juste le début de la puberté  :Evil or Very Mad: 

et ceux-là 

```
CFLAGS CXXFLAGS LDFLAGS
```

comment sont-ils ?

Le but ultime de l'instabilité : si je t'assure j'ai eu le prompt 2 secondes    :Cool: 

**********************************************

plus serieusement, il est possible d'avoir les deux :

le multiboot.

un gentoo stable en laquelle on est sûr à 100% 

pour moi "gentoo-etap05" ; c'est une pendule juste francisée qui va sur ses 8 mois , bien à part sur son disque , dans une partition Ext3.

Puis une autre gentoo que je fais lentement glisser vers le côté obscur de l'instabilité

( en ce moment je me prend les pieds dans le tapis pour un truc tout con:

l'instabilité demande beaucoup de rigueur ! )

conclusion : on peux avoir les deux ;faisons-on le

A+

----------

## man in the hill

Bonjour à tous !

je suis un nouveau utilisateur de gentoo et j'ai choisi de vivre l'expérience testing(unstable) qui me semble plus instructif et surtout qui donne une vrai sensation  d'être un funambule...je trouve que la version testing ne pose pas vraiment de problème majeur qui son résolus en général en utilisant le moteur de recherche qui est vraiment un outil remarquable pour débuguer... 

Gentoo-testing fait vivre un portable hp pavilion-64bit  zv6100[ Amd64 sempron 3200+ , carte graphique ATI xpress 200(PCIE) , une carte wifi Broadcom BCM4318] , une tour classique [C-mère msi-k8n-neo2 54g , Amd athlon64 3200+, carte graphique nvidia geforce fx 5700, carte réseau RTL-8169]...

Aussi gentoo-stable tournant sur un petit  serveur-hardened-32bit  headless (comme dirait Trevoke   :Very Happy:  )[C-mère asus A7N8X-X + 4DD dont un scsi-usb]...donc jusqu' à maintenant j'ai réussi à surmonter les problémes qui ne sont pas si fréquent que cela...

Donc en résumé Gentoo est un apprentissage permanent avec une documentation énorme ainsi que des outils puissants pour gérer le système   et surtout des développeurs qui écrivent  bien leurs codes et qui propose rapidement des solutions en cas de bug...je n'ai pas vraiment d'astuces à donner puisque je débute à par faire une recherche automatique avec le moteur ou on trouvera sûrement un topic ou encore mieux un howto qui nous aidera à avancer...

J'ai quand même essayer la version stable qques temps mais cela n'empêche en aucun cas les plantages et gérer les paquets masqués est assez pénible , je me suis même déjà retrouvé ds l'impossibilté d'upgrader de stable vs testing donc dorénavent je fait mes installe directement avec ACCEPT_KEYWORDS="~amd64" .

Voilà mon bla-bla-bla ,  just do ti with gentoo

                                                                                                     @ bientôt.

----------

## UB|K

 *nemo13 wrote:*   

> un gentoo stable en laquelle on est sûr à 100% 
> 
> pour moi "gentoo-etap05" ; c'est une pendule juste francisée qui va sur ses 8 mois , bien à part sur son disque , dans une partition Ext3.

 

Je faisais ça aussi dans le temps: un partoche à part pour essuyer les plâtres de mes experimentations mais j'ai arrêté car je me suis rendu compte que mes petites experiences ne nuissaient en rien à la stabilité du système. Je suis donc repassé à une seule gentoo en ~amd64 plus pas loin de 350 paquets hardmaskés (meric xorg), une trentaine keywordés ~x86 et même toute la partie "mono" du système démasquée (les applis mono comme muine ou beagle sont d'ailleurs les seules qui plantent occasionnellement).

Pour en revenir au sujet de ce "troll officiel", je pense que le vrai troll se situe dans l'énoncé même du troll: "stable vs instable". Car même si il est évident que les paquets en ~ARCH sont moins testés, peuvent poser des pbs lors des compilations, bref marchent moins "out of the box", il n'en reste pas moins qu'au final on a un système qui ne peut pas être qualifié d'instable. Certes, ça demande un peu plus de travail que lorsqu'on est en ARCH mais on ne perd quasiment rien en termes de stabilité.

Il me semble donc que les seules raisons valables d'etre en ARCH plutot qu'en ~ARCH sont:

-qu'on a pas envie ou pas le temps de gérer les petits problèmes posés par les paquets en ~ARCH

-qu'on a pas l'utilité (genre sur un serveur) ou l'envie de bénéficier des derniers paquets disponibles

Je rajouterais que l'on dispose avec portage d'outil tellement souple que les deux approches peuvent être combinées et que du coup, tout le monde y trouve son compte.

(désolé pour vos yeux mais ce post sans accents est sponsorisé par Xgl qui ne veut pas entendre parler d'un clavier au layout "fr", j'édite dès que j'ai fini de faire mumuse   :Mr. Green:  )

edit: voulou: ça, c'est fait.

----------

## DidgeriDude

Perso, je suis en stable avec un package.keywords qui doit contenir environ une soixantaine de softs en ~x86 ou -*.

Je trouve que le stable évite de se prendre trop la tête avec des versions bancales ou des dépendances à la c.. . J'utilise donc l'unstable spécifiquement pour tel ou tel paquet qui ne possède pas encore (dans sa version stable) une certaine fonctionnnalité qui m'intéresse.

De plus, je suis en USE="-gnome -kde" sur ma machine, et j'aime donc penser ne pas avoir trop de trucs superflus (malgré mon USE super gros car je ne suis pas fan de packages.use sauf pour des cas précis) et j'avoue ne pas avoir envie de me retrouver à devoir installer un package ~x86 qui va m'obliger à en démasquer tout un tas afin de fonctionner (sans garantie que ça marche d'ailleurs) ! Ce qui ne m'empêche pas de le faire de temps en temps histoire de m'amuser un peu et tester certains softs rigolos : Metisse, Looking Glass, etc.

Malgré ma vision des choses, je mets à jour très (ma femme dit trop !) souvent tout de même en suivant la GLSA de près.

Et hop, voilà ma modeste contrib...

----------

## gbetous

premier succes du troll : je m'étais jamais posé la question jusqu'à présent.   :Very Happy: 

à la vue des différents commentaires :

je vais paser mon PC perso en unstable

je laisse mon serveur en stable

vu que j'aime bien farfouiller, qu'apparemment ce n'est pas forcément ingérable, je me tente ca !!!

faites chauffer les compilos   :Cool: 

----------

## billiob

 *UB|K wrote:*   

> ce post sans accents est sponsorisé par Xgl

 

T'en as trouvé un; cherches les autres !

Pour être plus sérieux, je suis en stable, avec des paquets d'instable, et pas de problème. Je ne sais plus où j'ai vu ça (dans un sondage là-dessus je crois), mais les paquets de "stable" receveraient plus vite les patchs de sécurité. A vérifier.

[EDIT] c'est là !

----------

## geekounet

Bon ben moi, je suis en instable, avec qq paquets masqués et hard-masqués (xorg7, gcc4, ...) depuis mes débuts ya 2 ans. J'aime bien avoir un système le plus à jour possible (un sync tous les soirs ^^), et suivre l'évolution des logiciels, être le 1er a tester... Et puis j'ai pratiquement jamais de pb, c souvent réglé après une petite recherche.

Et je suis d'avis de garder du stable sur les machines sensibles comme  les serveurs, passerelles, etc. , notamment pour GLSA.

Voilà, j'ai nourri le troll   :Laughing: 

----------

## apocryphe

Moi le ~ ca me parait un peu fade, y a pas un truc au dessus qui foire vraiment ?

[On avait bien dit troll]

----------

## geekounet

LFS sans manuel ?

----------

## apocryphe

on peut mettre tout son system en -* ?

----------

## NoZ

Le principal problème de l'instable, c'est que ça prend sensiblement plus de temps

que le stable, c'est pour ça que je tendrai plutôt vers un système mixte, ou nos

applis favorites sont en ~ pour pouvoir participer au tests, et derrière le reste en

stable pour que ça tourne pépère......

Sinon actuellement, j'ai uniquement mon serveur sous Gentoo, base stable, mais au

final mixifié... et j'n'ai pas à me plaindre  :Smile: 

----------

## gulivert

Perso ma gentoo est en stable, quoi que plus pour longtemps car après lecture de ce post j'ai décidé de la mettre en instable. En espérant ne pas faire un mauvais choix. Par contre je suis le conseil de Guilc qui dit de maské les baselayout et portage en -prev.

De plus après consultation de package.keywords, je vois qu'il est vraiement trop fournit, du coup autant mettre tout en ~x86

On verra bien, étant plutot très témérère et toujours à la recherche de la dernière mise à jour, me voilà servi.

Merci pour ce post   :Smile: 

----------

## ghoti

 *NoZ wrote:*   

> Le principal problème de l'instable, c'est que ça prend sensiblement plus de temps
> 
> que le stable

 

Plus de temps à quoi ?

A fonctionnalités égales, Installer kde-3.4 prend à peu près le même temps.que kde-3.5.

xorg-7 prend moins de temps que xorg-6 car on compile moins de choses inutiles ...

Je ne dis pas que certaines versions instables ne sont pas plus longues à installer mais l'inverse est vrai aussi.

En moyenne, le temps de compilation est fort semblable.

Quant à la configuration, c'est bien souvent identique.

La plupart du temps, l'instable (~ARCH) ne pose pas de problème car un logiciel qui arrive à ce stade a déjà été fortement testé. 

Et si vraiment un paquet instable se révèle par trop coriace, cela prend 3 secondes 2 dixièmes pour le mettre dans packages.mask 

AMHA, la seule différence entre le stable et l'instable c'est que si un paquet stable plante, on a l'impression d'avoir le droit d'engueuler le développeur. 

Par contre, si un paquet instable plante, on se dit plus facilement que, oui, tous comptes faits, il est effectivement instable  :Wink: 

Finalement, le terme "stable" c'est pour se donner bonne conscience car il n'y a nulle part aucun contrat qui garantit qu'un paquet stable n'aura aucune faille...

Gulivert soulève aussi un aspect fort intéressant : quelle est l'approche la plus efficace,

- passer en full ~arch et masquer 10 paquets problématiques dans packages.mask

ou bien

- rester en stable et mettre dans packages.keyword 50 paquets dont on veut de toutes façons avoir la dernière version.

 :Question: 

Perso, je préfère gérer 10 paquets plutôt que 50 ...

(On a dit qu'on trollait, hein ?  :Wink:  )

----------

## boozo

'alute

a vous lire... tous ou presque... vous faites l'apologie du ~arch   :Confused: 

à ce rythme là vous allez finir debianeux   :Laughing: 

gentoo stable en serveur car tous les progs sont éprouvés mais trop vieux, et le reste du monde en unstable pour bénéficier des drivers pour le dernier gadjet wifi à la mode ou faire tourner "la fin du monde 3", avec la dernière nvidia XFT308-SE DTV-62 E compatible 23:64 à 2048Mo, disponible sur le cvs du projet depuis 06.00   :Evil or Very Mad: 

Sans rire, quel intérêt de conserver 2 systèmes si personne ne s'en sert et que tous tounent en unstable m^ les débutant puisque c'est si simple et que tout fonctionne à merveille... ou presque ?! dans qqes mois les geeks vont réclamer une gentoo "experimental" histoire de se démarquer encore c'est bien çà ?

Gérer un système en full unstable c'est fun et intéressant à plus d'un titre je vous l'accorde, celà dit pour être en accords avec cette politique cela implique : synchro tous les jours ; emerge uDvN{--oneshot --depclean} world ; revdep-rebuild et autre dep ! (sans compter la Search funct du forum, bugzilla, google etc.) mis-à-part le temps que celà demande, pour ceux qui bosse avec leur gentoo c'est super top à gérer du subir le bug de cairo qui empèche d'envoyer un mail de confirmation de livraison et j'en passe et des meilleures...

Et puis, qd vous vous prenez entre quatre yeux... est-ce bien utile d'avoir la dernière version de libchmeux+-2.9999_pre-RC4 dont la plupart d'entre-nous ne savent m^ pas quoi il retourne... tout juste que c'est une dependance de la dernière mouture d'un prog de dessin vectoriel en 3D ?!  pour les amateurs éclairés ou ceux qui utilisent au quotidien cette technologie ok mais pour ceux qui n'utilisent guère qu'openoffice, le web, la gmailbox ou leurs clés usb avec leurs clavier et souris sans fils sur une connection wifi, quel est la plus value ?   :Confused: 

Pour le fun du geek et pour faire avancer l'état de l'art ? soit ! mais qd m^... un système mixte c'est bien plus opérant pour le "commun des gentooistes" selon moi   :Razz: 

* Allez va... faites-vous les dents...  :Mr. Green:  *

----------

## apocryphe

boozo

Je pense que les gens passent en ~ le plus souvent en s'apercevant d'eux meme que leur package.keywords comporte 150 paquets... et qu'au final le ~ devient plus un besoin qu'un gadget comme tu le laisse entendre

je trouve sa tres bien qu'il existe une tel distinction dans portage, 3 niveau permet de gerer ce qu'on veut vraiment faire de sa distrib et de ce qu'on y attends

la legitimiter du testing est tout aussi justifier que du stable

je suis tres content d'avoir kde 3.5 ( sans avoir a gerer 35 paquets a demasquer ) et je trouve qu'il aporte une avancer notable... et j' ai pas eu besoin d'attendre 6 mois pour le voir apparaitre

par contre jpense que de faire un --sync ( toute les semaines) est preferable que de le faire tout les jours ( comme on a l habitude de faire en stable ), car y a pas mal de paquet qui sont desinstaller le lendemain...

----------

## truc

 *pierreg wrote:*   

> LFS sans manuel ?

 

dettux devrait faire l'affaire... blabla à son sujet  :Smile: 

Non je n'ai aucun scrupule à faire du OFF dans un troll...  :Razz: 

----------

## boozo

 *apocryphe wrote:*   

> Je pense que les gens passent en ~ le plus souvent en s'apercevant d'eux meme que leur package.keywords comporte 150 paquets... et qu'au final le ~ devient plus un besoin qu'un gadget comme tu le laisse entendre

 

tu me remets en mémoire le passage au kde-meta ; nombre d'entre-nous avions une soixantaine de packages dans le package.keywords et sans broncher et la le changement/évolution était autrement plus importante que le passage de kde-3.4 à 3.5 si tu me permets   :Wink: 

 *apocryphe wrote:*   

> je trouve sa tres bien qu'il existe une tel distinction dans portage, 3 niveau permet de gerer ce qu'on veut vraiment faire de sa distrib et de ce qu'on y attends ;la legitimiter du testing est tout aussi justifier que du stable

 

je suis entièrement d'accords avec toi mais si on résume l'ensemble des posts... c'est un quasi plébicite pour l'unstable en relégant la branche stable à une utilisation serveur ; d'où ma remarque volontairement provocatrice   :Smile: 

 *apocryphe wrote:*   

> par contre jpense que de faire un --sync ( toute les semaines) est preferable que de le faire tout les jours ( comme on a l habitude de faire en stable ), car y a pas mal de paquet qui sont desinstaller le lendemain...

 

là en revanche je ne te suis pas... c'est contradictoire... si un package est à désinstaller le lendemain c'est souvent pour une bonne raison (modification du code pour corriger un bug ; une faille de sécurité ; etc. ) et celà est d'autant plus sensible sur une ~arch pour en garantir la fiabilité à mon avis   :Rolling Eyes: 

----------

## mornik

Instable car je le vaux bien   :Cool: 

Bon sans rire j'suis très loin d'être aussi bon, mais au dépard je suis passé en instable car je voulais gdesklets et ils était pas en stable... J'ai hésité pas mal avant de franchir le pas (douloureuse experience de cooker, l'instable de mandriva pour ceux qui connaisses pas) Et pour les fous du troll il existe une une mandriva officiellement stable.

Pourquoi ne pas avoir fait de mélange ? je craignait pour la stabilité et le fonctionnement de ma macine (si si)

Et depuis c'est tranquille. Je met à jour tous les jours (5 paquets en gros à compiler par jour) et pas de problèmes particulier. De temps en temps une ppli ne redémarre pas (genre gjim aujourd'hui) maios je saits que ça ira mieux demain (j'ai la flème là). Et franchement j'y fait pas plus attention que ça. Pour moi c'est limite une stable l'instable. Faut dire que j'utilise ma machine uniquement en desktop.

Mes 2 cents de troll.

----------

## _droop_

 *apocryphe wrote:*   

> 
> 
> Je pense que les gens passent en ~ le plus souvent en s'apercevant d'eux meme que leur package.keywords comporte 150 paquets... et qu'au final le ~ devient plus un besoin qu'un gadget comme tu le laisse entendre

 

En même temps quand tu as 150 paquets dans package.keywords (ce qui est mon cas), mais que tu as mis une version pour chacun d'entre eux. Tu te dis plutôt, j'utilise de l'instable parce que ,pour le moment, j'en ai besoin, mais le stable finira bien par me rattrapper...

(Ou alors tu arrêtes pas de modifier les versions dans le package.keywords, et la tu te dis que t'aimes vraiment perdre ton temps...)

----------

## nemo13

dicton à la con :

 *Quote:*   

> l'instabilité c'est l'énergie nucléaire de la gentoo

 

soit tu surfes en ~arch et tu acceptes que celà peux te pêter à la gueule

soit tu gères tes besoins en utilisant package.keywords

je serai tendance package.keywords car c'est bien d'avoir les mains dans le moteur mais bon...

A+

----------

## marvin rouge

 *nemo13 wrote:*   

> soit tu surfes en ~arch et tu acceptes que celà peux te pêter à la gueule

 

Mouais. Ca fait 2 ans que je tourne en ~arch complet, et je pense qu'au total, j'ai eu un seul cas ou ça m'a "pété à la gueule". Et c'était dû à un baselayout.

Alors si on fait les comptes, et qu'on rapporte ça aux nombres de bugs de l'interface chaise/clavier, le risque est vraiment très faible. C'est pas vraiment instable.

----------

## ghoti

marvin rouge +1

J'ai toujours été en instable (doit bien faire 5 ans maintenant) et la seule fois où ça m'a pété à la gueule, c'était en fait une saloperie de disque IBM qui s'est payé un "click of death".

En conclusion : les disques IBM sont plus instables qu'une gentoo instable ...  :Laughing: 

----------

## -KuRGaN-

Ca me tente bien l'instable mais j'ai toujours eu un peur d'y "passer" car me dit à chaque fois que je vais galérer pour des conneries, genre des conneries de gcc, de mauvais lien !!

Moi je connais vraiment pas grand chose du système linux à par les bases, ce que je kiff c'est le réseau!

Alors selon vous, qu'est ce que pourrai m'apporter une unstable à un utilisateur comme moi à part une connaisance accélérer du système car comme le dit si bien maître zenuxoo:

 *Quote:*   

> Plus t'as de merde plus t'en apprend !!!

 

----------

## ghoti

 *-KuRGaN- wrote:*   

> car me dit à chaque fois que je vais galérer pour des conneries, genre des conneries de gcc, de mauvais lien !!

 

A ben tiens, gcc, c'est justement un des rares progs que je garde en "stable". Tout le reste, il y a moyen de rattrapper plus ou moins facilement mais gcc, là, c'est trop sérieux !

 *Quote:*   

> Moi je connais vraiment pas grand chose du système linux à par les bases, ce que je kiff c'est le réseau!
> 
> Alors selon vous, qu'est ce que pourrai m'apporter une unstable à un utilisateur comme moi à part une connaisance accélérer du système

 

Dans l'absolu : rien  !  :Cool:  Ou du moins, pas grand chose de décisif. 

Si seul le réseau t'intéresse, tu te sentiras peut-être plus à l'aise en ne démasquant que les paquets réseau. 

Mais en faisant comme ça, tu risques de chipoter beaucoup plus (démasquage manuel des dépendances en cascade) que si tu étais en full instable.

En même temps, il ne faut quand même pas perdre de vue que le passage en full instable proprement dit va prendre à peu près autant de temps que la première install puisque la plupart des paquets vont être upgradés  (à moins de ne pas faire d'emerge world mais alors, je ne vois pas l'intérêt ...) Et pour un retour en arrière, ce sera le même cinéma (à moins de repartir d'un backup)

Donc, pour utiliser l'instable, il faut soit avoir fait le choix depuis le début, soit être sérieusement motivé pour supporter une pseudo-réinstallation ...

----------

## NoZ

 *Quote:*   

> Par contre, si un paquet instable plante, on se dit plus facilement que, oui, tous comptes faits, il est effectivement instable 

 

Exactement, et ça, ça prend du temps à réparer......

----------

## ghoti

 *NoZ wrote:*   

>  *Quote:*   Par contre, si un paquet instable plante, on se dit plus facilement que, oui, tous comptes faits, il est effectivement instable  
> 
> Exactement, et ça, ça prend du temps à réparer......

 

echo le_paquet >> /etc/portage/packages.mask et basta !

C'est les 3 secondes 2 dixièmes dont je parlais plus haut  :Wink: 

A moins évidemment que tu ne veuilles collaborer au debuggage et dans ce cas ça peut en effet demander un certain investissement ...

----------

## kopp

Moi, je suis passé en ~x86 simplement parce que ça me barbait de devoir demasquer un paquet par ci, un paquet par là etc.

Comme ça je n'ai pas de soucis. Je rajoute même des paquets hardmask quand ça me plait. Au pire, le dit paquet plante, mais ça ne crash pas tout le système car je ne fais ça que pour des paquets non critiques, genre gaim, firefox etc. (Et bien entendu Gnome, parce qu'attendre deux mois pour que ça passe en ~arch... voilà quoi  :Smile: )

Reste que dans l'idée, mon système n'est pas fait pour être stable, donc pourquoi se limiter. Le reiser4, + pour l'accompagner un noyau over-mega-patché (nitro-sources) J'ai peur de rien  :Smile: 

Jusque là j'ai pas eu de gros problèmes avec ce système, ou alors c'était du à des mauvais choix....

Par contre c'est vrai que certaines lib nous font la guerre, genre dbus... m'énerve ce truc  :Smile: 

Pour les sync, avant, c'était quotidien, now ça tient plutot de l'hebdomadaire. C'est largement suffisant. Faut dire que je suis pas un fan du débug etc.

----------

## ghoti

 *kopp wrote:*   

> Par contre c'est vrai que certaines lib nous font la guerre, genre dbus... m'énerve ce truc .

 

Encore une victime d'ivman ? Remarque que contrairement à ce que tu laisses penser, c'est la version stable d'ivman qui a de mauvaises dépendances et qui fait tout foirer. 

En full instable, pas de problème. 

Bel exemple ou l'instable est plus stable que le stable !  :Mr. Green: 

----------

## kopp

Nan, gnome-volume-manager. Mais le groupe dbus, hal et gvm avait tendance à changer constamment à une époque, c'était très ingérable, le comportement changeant une fosi sur deux. Maintenant ça va un peu mieux  :Smile: 

----------

## yoyo

Bon, réveillons un peu ce troll fatigué ...   :Wink: 

Le sujet est "stable vs instable" et la plupart des échanges ont porté sur le fait que "bah oui mais instable c'est pas si instable que ça" etc.

Ma question est donc la suivante : qu'apporte le fait d'être en instable par rapport au fait d'être en stable ??

- Système plus rapide : à démontrer (en comptant le temps bouffé par les petits pépins occasionnels de pantage de compil libs mal linké etc.).

- Système plus sécurisé : apparemment ça n'est pas le cas puisque les patchs de sécurité ne sont pas forcément inclus rapidement dans la brache instable.

- Avoir la dernière version des baselayout/coreutils/bash etc. Pour quoi faire ?? Qu'est-ce qu'elles apportent de plus ??

Pour ce qui est de certains paquets comme les wm/dm qui "peuvent" apporter des nouvelles fonctionnalités intéressantes, je veux bien (et encore, toutes ne nous concernent pas forcément). Mais ça ne justifie en aucun cas le fait de passer en full-instable.

Voilà, à vos clavier !!!

----------

## d2_racing

Personnellement je suis en stable depuis le début (Juin 2005), sauf  que j'utilise le fichier /etc/portage/package.keywords pour mettre certains logiciels en unstable facilement.

C'est la première distribution qui me permet autant de flexibilité, car quand j'étais avec Debian, je pouvais le faire sauf que j'avais beaucoup trop de problème pour rien.

Et pour ce qui est de stable vs unstable, j'ai pas assez d'expérience contrairement à mes amis qui sont tous sur unstable, car ils aiment les défis.

Genre, ils sont presque tous avec KDE 3.5 avec le nouveau X.ORG en split-ebuild.

Bref, ils taponnent pas mal sur leur Gentoo pour le défi de le faire foncitonner et surtout pour apprendre  :Smile: 

En passant, c'est vraiment le fun d'avoir des amis comme ça, car je suis jamais à cour de solution  :Smile: 

----------

## ghoti

 *yoyo wrote:*   

> - Avoir la dernière version des baselayout/coreutils/bash etc. Pour quoi faire ?? Qu'est-ce qu'elles apportent de plus ??

 

En tout cas, elles n'apportent rien de moins si ce n'est une "possiblilité" d'instabilité qui, lorsqu'elle s'avère, n'est souvent pas dramatique.

La notion de "stabilité" est assez subjective et ne tient qu'à un petit "~" dans un fichier d'ebuild.

Perso, je trouve que la terminologie "stable/instable" est trop limitative et ne correspond pas à la réalité de gentoo.

Un paquet "vraiment" instable est un paquet "hard-masqué", soit dans packages.mask, soit avec le keyword "-" (signe "moins"). Ceux-là, ils ont toutes les chances de planter, à supposer qu'on arrive à les installer.

Mais ce que l'on définit habituellement comme "instables" sont des paquets "tildarchés" en transit vers l'état dit "stable".

C'est peut-être un peu "gamin", mais moi j'aime bien découvrir la toute-toute-toute dernière version ! (syndrome du Père Noël  :Wink:  )

Et sans être un génie de l'informatique ni vouloir la ramener, je pense avoir le minimum de connaissances requis pour me débrouiller en cas de pépin.

Dès lors, pourquoi bouder son plaisir ? (il y a peut-etre aussi le petit côté maso, va-t'en voir ! ...  :Laughing:  )

 *d2_racing wrote:*   

> Genre, ils sont presque tous avec KDE 3.5 avec le nouveau X.ORG en split-ebuild.

 

Oh oui, encore ...  :Laughing: 

----------

## niin

Allez je vais apporter ma pierre au troll et donner ma version du noob :

Mon système est à la base quasiment que en stable, mais je me suis vite rendu compte que jouer la prudence c'était bien chiant que on se tape un firefox 1.0.7 quand la version 1.5 est sortie depuis plusieurs semaines. Donc finalement, meme si je reste en stable, certains paquets valent la peine de les passer en ~x86 pour pas être a la traîne. Et en général ca ne pose pas de problème.

Il y a aussi les trucs qu'on a envie de tester de temps en temps, genre E17. Très franchement, j'ai testé et je suis revenu à E16, mais bon c'etait interessant. Et ca arrive sur d'autres trucs des fois. La par contre, une grande majorité des paquet de E17 ne sont que en -* donc c'est encore moins stable (d'ailleurs des fois ca s'installe meme pas chez moi).

Sinon j'avais une question : c'est quoi le mot clé pour avoir xorg-x11-7 ? Parce que moi, que je mette ~x86, ~ ou -*, je reste sur la 6.8.2-r2, et j'ai fait un emerge --sync hier.

----------

## yoyo

 *niin wrote:*   

> Sinon j'avais une question : c'est quoi le mot clé pour avoir xorg-x11-7 ? Parce que moi, que je mette ~x86, ~ ou -*, je reste sur la 6.8.2-r2, et j'ai fait un emerge --sync hier.

 C'est d'aller dans le sous-forum "Documentations, Astuces et Scripts" et de lire le thread : [HOWTO] Migration vers X modulaire.   :Wink: 

Enjoy !

----------

## Trevoke

J'ai commence en stable et je suis passe en instable apres environ un mois. Un ou deux mois apres, je me suis dit "Les devs disent que c'est limite impossible de repasser en stable, je vais essayer..."

J'ai essaye, j'ai pas trop casse de trucs, ca a marche.

Apres, bon, je suis repasse en instable parce que j'apprenais plus de trucs! De la, j'ai joue avec le nouveau GCC (3.4 a l'epoque, et puis un peu avec 4.0 et 4.1 dernierement), puis je me suis lasse et je l'ai remasque. Comme dit ghoti, c'est du serieux, et puis en fin de compte, c'est bien de pouvoir se servir de l'ordi quand t'as fini d'apprendre dessus!

Je dois avouer que je ne serais certainement pas aussi utile a la communaute que je ne le suis aujourd'hui (si, si, j'insiste) si je n'etais pas en instable.

Connaitre les outils pour reparer Gentoo, ca n'a pas de prix  :Smile: 

----------

## kopp

X.org est encore en hardmask, il y a tout une section de package.mask qui contient les noms des paquets qui sont masqués.

Il y a une documentation sur le forum et sur le site de Gentoo

Sinon, je trouve aussi que c'est plutôt mal nommé.

Toujours est il, l'arch-tildé, c'est pratique pour pas mal de paquets qui mettent du temps à venir.

EDIT : ultra-grilled  :Smile: 

 *Trevoke wrote:*   

> 
> 
> Connaitre les outils pour reparer Gentoo, ca n'a pas de prix 

 

pour le reste, il y a mastercard.

Enfin, moi j'accepte aussi les chèques et le liquide si ça te chante  :Wink: 

----------

## _droop_

Bonjour,

<off : passer d'instable à stable en douceur>

Une personne sur l'irc m'a demandé comment passer d'"instable" (~arch) à stable en douceur (arch), c'est à dire ne pas recompiler tous les paquets installés : laisser les paquets stables remplacer peu à peu  les instables (à chaque mise à jour). Je remet ma proposition au cas où (il faut si ce n'est pas encore fait, installer gentoolkit et remplacer arch par ce qui va bien pour vous)...

Enlever le ACCEPT_KEYWORDS et utiliser package.keywords pour rendre stables les paquets actuellement installés :

```
for i in `equery list -i | awk '{print $1}' | grep -v 'installed packages'`; do echo "=$i ~arch" >> /etc/portage/package.keywords; done
```

</off>

Bonne journée.

----------

## DuF

Perso c'est du stable suite à une mésaventure sur un emerge baselayout après 3 semaines de vacances... J'en ai conclu que mon cerveau n'était pas assez alerte et que j'avais besoin que les devs gentoo fassent la stabilité à ma place  :Smile: 

Par contre j'ai une tripotée de paquets orienté desktop qui sont dans le package.keywords comme beaucoup ici a priori.

----------

## marvin rouge

Grain de sel: y'a aussi le fait qu'à une époque, en archi amd64, il y avait très peu de paquets à jours dans la branche "stable". Pour avoir des paquets récents, il fallait les passer en ~amd64, voire tester des paquets x86 (ou ~x86) pour indiquer aux devs que ces paquets compilaient en ~amd64.

Bref, pour ne pas avoir de paquets antédiluviens, la solution était le tildarchage (joli, non ? J'imagine une arche romane, avec un tilde au milieu.).

De fil en aiguille, l'habitude se prend de rester en "instable". Et comme beaucoup de monde, je trouve cette dénomination mal choisie. Peut-être "branche non garantie de plantage" ?

+

----------

## truc

arf, mj'adore le principe de keyworder quelques paquets etc.. je trouve ça vraiment très bon, mais à vous entendre j'ai envie de faire un bon(d) dans le coté obscure..( :Laughing:  à ceux qui saisissent ce jeux de mots pourri..). Puis pourquoi pas, à l'instar de Trevoke, repasser en stable etc..

----------

## Trevoke

Repasser en stable c'est vraiment pas recommande a moins que tu n'aies du temps a investir, parce que tu ne sais jamais ce que ca va casser ou non.. Et puis quand tout est en instable, des fois y a une version instable que t'aimes beaucoup (kde 3.5 et pas 3.4 par exemple) ..

M'enfin fais ce que tu veux. Simplement, viens pas pleurer quand tout est casse, on t'a prevenu!   :Twisted Evil: 

----------

## ghoti

 *Trevoke wrote:*   

> Repasser en stable c'est vraiment pas recommande a moins que tu n'aies du temps a investir, parce que tu ne sais jamais ce que ca va casser ou non

 

Une question me vient tout de même à l'esprit car je n'ai jamais fait l'exercice : d'après ce que tu laisses supposer, repasser de l'instable au stable serait plus périlleux que l'inverse ??? J'avoue que j'ai du mal à imaginer pourquoi   :Question: 

----------

## Trevoke

Parce que certaines dependances pourraient se trouver cassees a la suite d'un retour *general* a des versions inferieures.

J'avoue que je trouve ca etre un peu moins vrai aujourd'hui qu'il y a un an, vu que Gentoo devient, en general, plus stable partout, mais imagine repasser a un glibc inferieur et a un portage inferieur, par exemple..  :Smile: 

----------

## ghoti

 *Trevoke wrote:*   

> mais imagine repasser a un glibc inferieur et a un portage inferieur, par exemple.. 

 

L'argument est recevable !  :Wink:   :Laughing: 

----------

## truc

 *Trevoke wrote:*   

> Repasser en stable c'est vraiment pas recommande a moins que tu n'aies du temps a investir, parce que tu ne sais jamais ce que ca va casser ou non.. Et puis quand tout est en instable, des fois y a une version instable que t'aimes beaucoup (kde 3.5 et pas 3.4 par exemple) ..
> 
> M'enfin fais ce que tu veux. Simplement, viens pas pleurer quand tout est casse, on t'a prevenu!  

 

arf, une chose est sûre, je ne piquerai pas ta manière de parler... je sais c'est du réchauffé. mais je te trouve aggressif!  :Smile:  :Smile:  je chiale pas, je demande de l'aide si besoin est  :Smile:  allez c'est pas grave...

 :Rolling Eyes: 

----------

## Trevoke

Aggressif? Moi? Tu veux une baffe?   :Laughing: 

----------

## truc

 *Trevoke wrote:*   

> Aggressif? Moi? Tu veux une baffe?  

 

qu'est ce que je disais!  :Wink: 

----------

## Trevoke

Je ne fais que repeter ce que les devs disent.. C'est tres dur de repasser en stable a cause de tous les changements subtils qui sont faits, et je ne le recommande pas  :Smile: 

----------

## Qc_Fox

je vien de me décider de changer pour la branche unstable apres plusieur année a joueur avec le package.keywords ou faire ACCEPT_KEYWORDS="~x86" très souvent pour installer des packages. Je vais en avoir pour une semaine ou 2 de compilation je pense bien hehehe. 

Es-ce que kek1 pourrais me dire si en faisans un emerge -u world , si ca va changer mon kde 3.4.2 pour un 3.5

Et quelle est la putain de commande pour lister tous les packages installer su la machine ou y a-t-il un fichier ou la liste des package est ecrite

----------

## nemo13

bonsoir,

avec un 

```
emerge -ave world
```

 tu auras tout ce qui est dans ta babasse.

( je ne me rappelle plus comment faire avec equery désolé   :Crying or Very sad:   )

----------

## k-root

 *nemo13 wrote:*   

>  je ne me rappelle plus comment faire avec equery désolé  :cry:  

 

```
equery l
```

----------

## yoyo

 *Qc_Fox wrote:*   

> Es-ce que kek1 pourrais me dire si en faisans un emerge -u world , si ca va changer mon kde 3.4.2 pour un 3.5
> 
> Et quelle est la putain de commande pour lister tous les packages installer su la machine ou y a-t-il un fichier ou la liste des package est ecrite

 Mouais, c'est pas pour faire mon chiant mais raccourcir "quelqu'un" à "kek1" et prendre le temps d'écrire "la putain de commande" alors que "la commande" aurait suffit je trouve ça un peu limite ...   :Confused: 

----------

## Zanfib

[off] je croyais que c'étais un pseudo kek1, zut je suis déçu là !!   :Laughing:  [/off]

Sinon moi aussi j'ai installé ma première gentoo en stable sur un athlon XP, 2 semaines plus tard j'étais en ~x86 pour profiter des dernières versions de beaucoup de logiciels, je ne connaissais pas encore bien les subtilités du répertoire /etc/portage ... je suis même en train de me demander si ça existait déjà à l'époque   :Question: 

Depuis je suis passé à l'amd64 et là j'ai installé en ~amd64 de suite !!! Bon là j'ai eu plus de petits soucis mais j'ai beaucoup appris en me dépatouillant de ces petits bugs, en grande partie grâce au forum d'ailleurs, merci à tous au passage !!!   :Very Happy: 

Je dirai : 

* un système tranquille sans anicroches et si on n'est pas accros à la dernière version = stable

* un système pour être à la pointe et contribuer activement à la vie de la gentoo = instable

* devenir développeur gentoo = -*   :Twisted Evil: 

Voilà mes 2 cents   :Wink: 

----------

## marvin rouge

 *Qc_Fox wrote:*   

> Et quelle est la putain de commande pour lister tous les packages installer su la machine ou y a-t-il un fichier ou la liste des package est ecrite

 

Ne sous-estimons pas la puissance de eix:

```
eix -c -I
```

Rapide, efficace. Les paquets du world et les dépendances. eix, c'est bon, mangez en.

----------

## _droop_

 *Trevoke wrote:*   

> Je ne fais que repeter ce que les devs disent.. C'est tres dur de repasser en stable a cause de tous les changements subtils qui sont faits, et je ne le recommande pas 

 

Bonjour,

Je suis tout à fait d'accord avec toi, mais j'ai expliqué sur la page précédente la manière douce pour repasser en stable : c'est à dire enlever le ACCEPT... et indiquer que tous les paquets actuellement installés sont stables. Après ça met le temps. Après ça va mettre le temps pour réellement revenir en stable (petit à petit à chaque mise à jour). Mais ça évites le downgrade de paquets potentiellement dangereux (libc, gcc...).

Bonne journée.

----------

## SuperDindon

ln -s /usr/portage/profiles/package.mask /etc/portage/package.unmask

----------

## ghoti

 *SuperDindon wrote:*   

> ln -s /usr/portage/profiles/package.mask /etc/portage/package.unmask

 

Mouais, ça, par contre,  c'est la définition exacte de la bombe nucléaire !   :Twisted Evil: 

----------

## Trevoke

_droop_ : oui mais c'est la solution 'facile' ca! M'enfin! D'abord!  :Smile: 

Ce qui me fait rigoler c'est qu'on n'arrive pas a etre d'accord sur stable ou instable mais visiblement tout le monde est en instable ...  :Smile: 

----------

## truc

et non  :Wink:  j'suis en mi-nstable  :Laughing: 

----------

## TGL

 *_droop_ wrote:*   

> Je suis tout à fait d'accord avec toi, mais j'ai expliqué sur la page précédente la manière douce pour repasser en stable : c'est à dire enlever le ACCEPT... et indiquer que tous les paquets actuellement installés sont stables. Après ça met le temps. Après ça va mettre le temps pour réellement revenir en stable (petit à petit à chaque mise à jour). Mais ça évites le downgrade de paquets potentiellement dangereux (libc, gcc...).

 

Ça en évite un certain nombre, mais c'est quand même loin d'être infaillible. Le truc, c'est que bien souvent des versions d'ebuilds ne deviendront jamais stables, parcequ'elle auront été remplacées par d'autres avant la fin de leur quarantaine. 

Par exemple, foolib-1.0 est stable, foolib-1.1 est ~arch (ta version installée et listée dans package.keywords). Un bug est trouvé dans foolib-1.1, et il est bumpé en 1.1-r1 avec nouveau patch, et le 1.1 disparait de l'arbre. Seule la 1.0 reste donc légale pour toi, et emerge fera un downgrade. Idem pour un passage de 1.1_pre20050101 en 1.1_pre20050206, ou 1.1_rc4 en 1.1_rc5, et beaucoup d'autres, où c'est une mise à jour qui serait le plus sûr, alors que tu vas faire au mieux ne rien changer, et au pire faire un downgrade vers 1.0 si l'ebuild a disparu.

Bon, c'est pas un drame non plus, mais c'est juste pour dire que ta méthode n'évite pas d'avoir à surveiller très attentivement ses "emerge -p ..." et d'y traquer les downgrades, pour bien se demander s'il sont souhaitables ou non.

Perso je pense qu'une façon de limiter cet effet est de générer ce package.keywords avec des contraintes de versions un peu plus souples. Moi j'aurai plutôt tendance à utiliser des "=paquet-version*", en virant les -rX et les  _pre/_rc/_alpha/_beta/_p. Genre comme ça : 

```
# cd /var/db/pkg

# ls -d */* | sed -e 's:-r[0-9]\+$::' -e 's:_\(pre\|alpha\|beta\|rc\|p\)[0-9]*$::' -e 's:.*:=\0*  ~ARCH:' >> /etc/portage/package.keywords
```

Bon, évidemment, avec cette technique, il arrive qu'on keyword des micro mises-à-jour qu'il aurait été possible d'éviter, etc. Mais bon, c'est pas si grave, ça ralentit juste le retour vers stable de certains paquets, mais c'est pas particulièrement risqué. Bref pour moi c'est un bon compromis.

D'autres pourront préférer utiliser juste des "~paquet-version", qui permettent d'accepter uniquement les revision bumps. Ils rateront par contre d'éventuels passages de _beta2 à _beta3, etc. :

```
# ls -d */* | sed -e 's:-r[0-9]\+$::' -e 's:.*:~\0  ~ARCH:' >> /etc/portage/package.keywords
```

Ou bien encore, un mix des deux : des ~foo-1.1 pour les paquets ayant des numéros de version normaux, et des =foo-1.1* pour ceux qui étaient installé en tant que foo-1.1_beta2 ou assimilé : 

```
# ls -d */* | sed -e 's:-r[0-9]\+$::' -e 's:_\(pre\|alpha\|beta\|rc\|p\)[0-9]*$:*:' -e '/\*$/s:.*:=\0  ~ARCH:' -e '/^=/!s:.*:~\0  ~ARCH:' >> /etc/portage/package.keywords
```

Enfin bref, quoi qu'il en soit, rien n'évite complètement de bien inspecter ses "emerge -p ...", c'est évident. Mais de toute façon, on le fait tous déjà, non ?Last edited by TGL on Fri Feb 10, 2006 2:05 pm; edited 1 time in total

----------

## blasserre

 *Trevoke wrote:*   

> _droop_ : oui mais c'est la solution 'facile' ca! M'enfin! D'abord! 
> 
> Ce qui me fait rigoler c'est qu'on n'arrive pas a etre d'accord sur stable ou instable mais visiblement tout le monde est en instable ... 

 

Bah le problème c'est que quand on est en stable (comme moi) on à pas grand chose à dire et même, à la limite, on a un peu honte !

Mais bon, c'est une question de caractère, je suis plutôt patient comme type... j'ai attendu la sortie du 2.6 pendant... ourf, depuis qu'on à commencé à en parler en fait. Donc partant de là, la killer feature, l'acpi pourri qui t'oblige à éteindre ton portable avec ton doigt (plutôt qu'automatiquement) quand il n'y a plus de batterie, tu temporises.... un jour ça sort et tu oublies que t'as attendu ça pendant trop longtemps.

Sinon, un avantage non négligeable est que tu évites l'incompréhension de ta partenaire qui, t'ayant vu passer le week end sur la babasse, à le malheur de lancer le nouvel amarok qui tue sa mère et se retrouve éjectée de la session. Vas justifier ton refus de déjeuner chez belle-maman le dimanche !  :Laughing: 

Pour finir sur une note positive, quand je compare mes versions de softs et celles utilisées dans le monde professionnel, bah je me dis gentoo stable c'est de l'expérimental...

----------

## boozo

bah... moi j'ai les deux en parallèle maintenant donc au boot çà dépendra de mon humeur du moment   :Wink: 

et à la lecture de l'argumentation de blasserre je suis dans l'obligation de faire un petit

```
mount -o bind /dev/blasserre /dev/boozo
```

et me joindre à ses remarques   :Razz: 

----------

## nemo13

[quote="TGL"] *_droop_ wrote:*   

> 
> 
> Par exemple, foolib-1.0 est stable, foolib-1.1 est ~arch (ta version installée et listée dans package.keywords). Un bug est trouvé dans foolib-1.1, et il est bumpé en 1.1-r1 avec nouveau patch, et le 1.1 disparait de l'arbre. Seule la 1.0 reste donc légale pour toi, et emerge fera un downgrade. Idem pour un passage de 1.1_pre20050101 en 1.1_pre20050206, ou 1.1_rc4 en 1.1_rc5, et beaucoup d'autres, où c'est une mise à jour qui serait le plus sûr, alors que tu vas faire au mieux ne rien changer, et au pire faire un downgrade vers 1.0 si l'ebuild a disparu.
> 
> Bon, c'est pas un drame non plus, mais c'est juste pour dire que ta méthode n'évite pas d'avoir à surveiller très attentivement ses "emerge -p ..." et d'y traquer les downgrades, pour bien se demander s'il sont souhaitables ou non.
> ...

 

Bon j'ai pas très compris les VALEURS (dois-je dire Sirot ou Pousse-Sirot )

 :Embarassed: 

on pourrait faire une partie  :Laughing: 

là vous êtes stratosphériques. va me falloir au moins 10ans pour essayer d'absorber

bonne Journée

[EDIT] en plus je "monte" en grade en disant des conneries ; comme quoi la "valeur" et le positionnement !!!

----------

## Argian

 *nemo13 wrote:*   

> Bon j'ai pas très compris les VALEURS (dois-je dire Sirot ou Pousse-Sirot )
> 
> on pourrait faire une partie 
> 
> 

 

sed avec la commande s et tout plein de regexp's, c'est un Contre-Sirop, mais ce n'est pas à toi de le dire puisqu'on tourne dans le sens des valeurs  :Razz: 

Tu peux faire un "info sed" ou un "man grep" pour tout plein de détails croustillants et si tu comprends tout, tu monteras en grade encore plus vite  :Very Happy: 

 *boozo wrote:*   

> et à la lecture de l'argumentation de blasserre je suis dans l'obligation de faire un petit 
> 
> ```
> mount -o bind /dev/blasserre /dev/boozo
> ```
> ...

 +1

----------

## truc

sniff, j'arrive tout content cette semaine pensant que j'aurai un nouveau DOW, mais euh, c'est encore celui là?   :Rolling Eyes: 

 :Very Happy: 

----------

## yoyo

 *truc wrote:*   

> sniff, j'arrive tout content cette semaine pensant que j'aurai un nouveau DOW, mais euh, c'est encore celui là?  

 Le suivant est en cours de sélection ...

Il devrait arriver incessamment sous peu.

Enjoy !

----------

## dapsaille

 *apocryphe wrote:*   

> Moi le ~ ca me parait un peu fade, y a pas un truc au dessus qui foire vraiment ?
> 
> [On avait bien dit troll]

 

Alors la oui .... je dis oui depuis le début (ou presque ) j'ai un p4 en ~x86 un amd64 en ~amd64 et un dudu en ~x86 ..

 bah ou qui sont les risques ???

 Honnetement je leve ma main droite et je le jures,

Je trouves mes instables bien plus stables que les debian stables de mes amis .. sisi ....

 quoi c'est fini ce dow ?? mince .. bah je l'aurais dit quand meme ...

 Et pis faut avouer que des que y'as des trucs à tester ... je teste :p

----------

## TGL

Désolé de réveiller un troll qui dort, mais je viens enfin de trouver un truc pertinent qui n'aurait pas déjà été dit : oui, les vilains b0rkage en ~arch ça existe (même si moi non plus je n'en vois pas tous les jours).

C'est le cas du bug #123342 : chez certains, coreutils-5.94 fournissait un /bin/expr qui segfaultait à tout va. Or sans expr, point de salut pour les scripts configure, et donc impossible d'installer quoi que ce soit, y compris une nouvelle version de coreutils corrigeant le problème... Ceux qui ont été victimes de ce bugs n'ont pu s'en tirer que si ils avait busybox d'installé (parceque busybox permet de remplacer de nombreuses commandes de base, dont expr), ou bien en récupérant un binaire de expr depuis une autre machine ou une autre distribution.

Ça, c'est typiquement le genre de bug assez galère qui n'arrive qu'en ~arch. Rien d'insurmontable évidemment, et puis c'est pas fréquent non plus, mais quand même, je trouvais l'exemple intéressant pour tempérer un peu l'enthousiasme général quant à la stabilité de la branche de test.

----------

## -KuRGaN-

Et juste une petite question qui me turlupine au passage avant de refermer ce DOW !!

Comment on fait pour mettre Windaube en stable ?????????,,

Bon d'accord, j'ai compris:   :Arrow:  [.]

----------

## anigel

Je fais partie des "petits enfants sages" de ce forum : j'utilise Gentoo en stable. Mais j'ai ajouté à ma liste de trucs à faire : tester gentoo en ~arch. Je me demandais donc, parmis ceux qui tournent depuis longtemps avec ce type de système, quels étaient les paquets auxquels vous faisiez particulièrement attention ?

A priori, je serais partie pour laisser baselayout, glibc et gcc en stable. TGL me laisse à penser qu'il peut être judicieux d'ajouter à cette liste les coreutils. D'autres idées / expériences ?

----------

## geekounet

Perso, j'ai tout en instable avec quelques paquets hard-masked aussi, mais je fais assez attention à gcc, j'attends des retours sur les nouvelles versions avant d'upgrader, et j'ai toujours un gcc 3.4 de côté au cas où : si l'un ne marche pas, l'autre marchera toujours.

Pour la glibc, je m'en suis jamais soucié, j'ai jamais eu de pb.

Le baselayout, ben je prends le risque, si ça marche pas, c jamais trop grave.

Et pour portage, on peut toujours le réparer s'il marche plus avec ça : http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml

Sinon, je dirai qu'il faut aussi faire attention à python, aux coreutils, aux binutils, ... tout les trucs critiques qui font que portage peut ne plus être fonctionnel. Si portage marche, on peut tout réparer  :Wink: 

----------

## TGL

 *anigel wrote:*   

> A priori, je serais partie pour laisser baselayout, glibc et gcc en stable. TGL me laisse à penser qu'il peut être judicieux d'ajouter à cette liste les coreutils. D'autres idées / expériences ?

 

En même temps, pour glibc et gcc je dis pas, mais pour baselayout c'est presque dommage de se priver de la série 1.12.0_pre, qui est pleine d'améliorations appréciables...

En fait, perso, ma technique n'est pas d'exclure quoi que ce soit du ~arch, mais plutôt de conserver des paquets binaires des trucs potentiellement critiques. Comme ça, en cas de pépin, j'ai sous le coude de quoi revenir à une version précédente (que ce soit direct avec un "emerge -K =cat/pkg-x.y", ou bien éventuellement depuis un LiveCD si le problème empêche Portage de fonctionner, ou m'empêche de me booter, ou n'importe quoi dans ce style là). 

Une solution bourrine pour faire ces binaires est d'utiliser le FEATURES flag "buildpkg", mais là, gare à l'espace que les binaires vont vite occuper. 

Une demi-solution est d'utiliser plutôt le flag "buildsyspkg", qui va en produire uniquement pour les paquets de la classe system. C'est déjà mieux, mais là par contre ça n'inclue pas leurs éventuelles dépendances. 

Enfin, une approche intermédiaire est de viser un peu plus large que le buildsyspkg, avec une liste personnalisée des paquets à binariser. C'est ce que j'utilise, mais ça implique de patcher Portage. Si y'a des gens que ça intéresse, ils peuvent essayer ça (pour portage-2.1_pre4 ou _pre5) : 

```
# cd /tmp

# wget http://tdegreni.free.fr/gentoo/portage-2.1_pre4-BUILD_PKGS.patch

# cd /usr/lib/portage

# patch -p1 --dry-run < /tmp/portage-2.1_pre4-BUILD_PKGS.patch

# # et si le dry-run ne donne pas d'erreur...

# patch -p1 < /tmp/portage-2.1_pre4-BUILD_PKGS.patch
```

 Ensuite, il ne reste plus qu'à faire sa liste dans /etc/make.conf. Perso, j'y mets "system" (ça remplace le FEATURES flag dont je parlais au dessus), enfin sauf les sys-kernel,  plus quelques autres catégories ("sys-*", "*-libs", etc.) et quelques applis réputées pour leur temps de compilation : 

```
BUILD_PKGS="system !sys-kernel sys-* \

   dev-cpp dev-lang dev-libs dev-python dev-util \

   app-office/openoffice www-client/mozilla-firefox kde-*"
```

 Bon, c'est déjà plus safe, mais ça prends plus de place (qlqs centaines de Mo en gros). Mais ça a le gros inconvénient de ne pas être une méthode très standard, vous l'aurez compris... Ce qui devrait en principe l'être un jour par contre, c'est la possibilité de définir à peu près n'importe quoi comme environnement pour des ensembles de packages, et donc de pouvoir définir FEATURES="buildpkg" pour ceux importants.

----------

## PabOu

j'ai toujours tourné en unstable ~x86 sur toutes mes machines et je ne vois pas l'intéret d'être en stable.

l'unstable est tellement stable.. si si !

je mets pas à jour tous les jours, ni meme toutes les semaines. ca ressemble plutot à une fois toutes les 3 semaines...

et puis c'est tellement marrant (j'aime ce genre de chipottage :) ) quand un truc ne va plus (ca arrive pas souvent.. bien souvent c'est juste des ebuilds qui compilent plus ou des ebuilds qui en masquent d'autres et qui rendent la mise à jour plus difficile).

sur ma machine princpale :

 *Quote:*   

> CFLAGS="-mtune=athlon-xp -march=athlon-xp -O2 -pipe -fomit-frame-pointer -m3dnow -msse -mmmx -falign-functions=4 -ffast-math -mfpmath=sse,387 -DPIC"
> 
> CFLAGS="${CFLAGS} -fPIC"
> 
> CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
> ...

 

et quand quelque chose foire apres compilation (xorg non modulaire par exemple), je commente la 2eme ligne CFLAGS :) (pour retirer le -fPIC) et je recompile ;)

sinon je ne fais attention à aucun paquet spécialement, mais en lisant le sujet, c'est vrai que baselayout et dhcpcd m'ont déjà posé quelques problèmes (pour le script net principalement), alors faut bien faire attention dans l'utilisation d'etc-update

sinon c'est l'habituel probleme quand on change de version de gcc à jour (je suis peut-etre pas tres prudent avec mes gentoos, je le sais, et c'est peut-etre pour ca que je ne veux pas passer à gcc 4.x).. libstdc++.so introuvable

edit : ah ouais, quand j'ai un probleme que je n'arrive pas à résoudre, je fais une recherche sur le forum, et quand je ne trouve pas, sur bugzilla

----------

## Enlight

Autant ça me parraît bien pensé le -DPIC (soit les macros sont adaptées, soit pas) autant le -fpic me parraît brutal... mais au final pourquoi tu ne te simplifie pas la vie en les virant et utilisant le USE pic et en laissant ainsi le travail aux configure et au make?

----------

## ghoti

 *TGL wrote:*   

> Une solution bourrine pour faire ces binaires est d'utiliser le FEATURES flag "buildpkg", mais là, gare à l'espace que les binaires vont vite occuper. 

 

A signaler aussi : quickpkg : très pratique pour fabriquer un binaire à postériori !

----------

## PabOu

 *Enlight wrote:*   

> Autant ça me parraît bien pensé le -DPIC (soit les macros sont adaptées, soit pas) autant le -fpic me parraît brutal... mais au final pourquoi tu ne te simplifie pas la vie en les virant et utilisant le USE pic et en laissant ainsi le travail aux configure et au make?

 

parceque je n'en connaissais pas l'existence. je vais voir de plus près.. mais aucun ebuild (ou presque) n'a ce flag je suppose...

----------

## geekounet

Bon là, je suis en train d'installer une gentoo à mon ptit frère ^^, et j'avoue que je préfère lui installer une gentoo en stable : pour la facilité de la maintenance et pour ne pas trop me prendre la tête. Il y aura qq trucs que je mettrai en instable quand même, comme firefox par exemple.

J'ai aussi fait ce choix parce qu'il va aussi s'en occuper lui-même de l'admin, donc je préfère ne pas prendre de risques et être sur que ça marche tout seul pour lui  :Smile: 

Mais bon j'ai quand même l'impression de revenir 6 mois en arrière  :Laughing: 

----------

## dapsaille

 *pierreg wrote:*   

> Bon là, je suis en train d'installer une gentoo à mon ptit frère ^^, et j'avoue que je préfère lui installer une gentoo en stable : pour la facilité de la maintenance et pour ne pas trop me prendre la tête. Il y aura qq trucs que je mettrai en instable quand même, comme firefox par exemple.
> 
> J'ai aussi fait ce choix parce qu'il va aussi s'en occuper lui-même de l'admin, donc je préfère ne pas prendre de risques et être sur que ça marche tout seul pour lui 
> 
> Mais bon j'ai quand même l'impression de revenir 6 mois en arrière 

 

<vent trollesque> wahouu stable chez gentoo = 6 mois  en arrière z'etes vachement avancé sous deb ca correspond a 6 ans </vent trollesque>

 D'un autre cote en foutant ton frere en unstable il apprendras   :Twisted Evil: 

----------

## GNUtoo

 *pierreg wrote:*   

> LFS sans manuel ?

 

bah y'as pire...

va dans le bugday ou bugzilla et essaie de resoudre les bugs des gens...lol

----------

## Dominique_71

La plus grande partie de mon système de base est en stable. Pour gcc, je ne sais pas trop car j'utilisais gcc 3.4.4 comme seul compilateur de mon système 6 mois avant la sortie de 2006.0 Je crois qu'il est en stable aussi dans 2005.n maintenant.

Autrement, quand je veux la dernière version d'un programme, je le met en ~x86, ceux ci sont avant tout des programmes multimédias et sons. J'ai aussi tous les programmes de cet overlay: pro audio production applications portage overlay  :Very Happy: 

Le prochain truc que j'envisage de faire est d'uppgrader à gcc 4, car ce dernier à quelques optimisations supplémentaires, mais je ne suis pas pressé car mon système fonctionne bien.

----------

## kernelsensei

 *Dominique_71 wrote:*   

> Le prochain truc que j'envisage de faire est d'uppgrader à gcc 4, car ce dernier à quelques optimisations supplémentaires, mais je ne suis pas pressé car mon système fonctionne bien.

 

Je suis justement entrain de tout recompiler avec gcc-4.1 sur mon amd64, avec -ftree-vectorize d'activé ... je repasserai pour dire ce qu'il en est  :Wink: 

----------

## Dominique_71

J'aimerais bien savoir quel thred tu suis pour cet uppgrade à gcc 4.

Ceci dit, je n'utilise pas ACCEPT KEYBOARD=~x86 dans make.conf mais uniquement /etc/portage/package.keyboard.

Le problème avec ACCEPT KEYBOARD est que quand tu fais un uppgrade du système avec emerge, 

```
emerge --update --deep --newuse world
```

portage peut vouloir uppgrader tout le toolkit de base du système y compris gcc et glib. Or un tel uppgrade ne fonctionnera pas car le toolokit de base du système doit être compilé non pas avec l'ancien compilateur et l'ancienne glib, mais avec lui-même et la nouvelle glib pour fonctionner. Ce qui implique une double compilation du toolkit, et aussi pour être sur que rien n'est cassé, une double compilation de tout le reste.

----------

## PabOu

une petite rectification : KEYWORDS et pas KEYBOARD ;)

je suis intéressé par les résultats de GCC-4.1 !

----------

## kernelsensei

 *Dominique_71 wrote:*   

> J'aimerais bien savoir quel thred tu suis pour cet uppgrade à gcc 4.

 

Bah euh, j'ai démasqué la version 4.1, j'ai changé 2 trucs dans mes cflags (-ftree-vectorize -ftree-vectorizer-verbose=1) et puis j'ai fait 

```
emerge -1 libtool && emerge -ave system && emerge -ave world
```

----------

## Dominique_71

Comme tu fais, il me semble que tu sa toujours l'anceinne version de gcc et sans doute aussi de glib dans ton système. Cela va fonctionner sans problème.  Par contre, ce qui m'intéresse c'est d'avoir un système qui ne tourne que sous gcc 4, et là pour pouvoir enlever les anciennes versions, il faut recompiler deux fois le toolkit, une fois avec l'ancien compilateur et une nouvelle fois avec le nouveau toolkit pour obtenir un toolkit compilé avec le nouveau toolkit.

Gentoo Linux GCC Upgrade Guide

En français, cela donne que pour uppgrader de gcc 3.4 ou supérieurs à gcc 4.0 il faut:

# emerge -uav gcc

(substituter "i686-pc-linux-gnu-3.4.5" avec la version de GCC

et le CHOST sur lequel vous upgradez:)

# gcc-config i686-pc-linux-gnu-3.4.5

# source /etc/profile

(Reconstruire libtool)

# emerge --oneshot -av libtool

Reconstruire le système de base avec le nouveau compilateur:

# emerge -eav system

Reconstruire tout y compris le système de base avec le nouveau compilateur:

# emerge -eav world

Supprimer l'ancien compilateur (Remplacez gcc-3.3* par le nom de l'ancien compilateur):

# emerge -aC =sys-devel/gcc-3.3*

Je n'ai pas testé, mais cela devrait fonctionner. gcc-config sert à indiquer au système quel compilateur il doit utiliser. Sans cela, il continuera d'utiliser l'ancien. 

Cette procédure est beaucoup plus simple que celle que j'avais utilisé pour uppgrader à 3.4.4 car l'API change entre 3.3 et 3.4.

----------

## TGL

Arf, c'est la 2ème fois que je déterre ce débat, mais je peux pas m'empêcher, c'est trop beau là... 

Bug #131780 : un joli "rm -rf /" lors d'une install' de la glibc-2.4-r2... Oops   :Rolling Eyes: 

Nous avions presque unanimement salué ici la relative stabilité de ~arch ? Et bien le moins qu'on puisse dire c'est que cette exception confirme dignement la règle.

----------

## BuBuaBu

 *TGL wrote:*   

> Arf, c'est la 2ème fois que je déterre ce débat, mais je peux pas m'empêcher, c'est trop beau là... 
> 
> Bug #131780 : un joli "rm -rf /" lors d'une install' de la glibc-2.4-r2... Oops  
> 
> Nous avions presque unanimement salué ici la relative stabilité de ~arch ? Et bien le moins qu'on puisse dire c'est que cette exception confirme dignement la règle.

 

Il semblerai quand même que cela rentre dans un cas bien particulier, et apparement n'a pas pu être reproduit.

Qui a installé glibc-2.4-r2 ?

----------

## TGL

 *BuBuaBu wrote:*   

> Il semblerai quand même que cela rentre dans un cas bien particulier

  C'est toujours sur des cas particuliers que portent les bugs, et on sait qu'on ne peut pas les prévoir tous... Seulement voilà, sachant ça, en général quand on écrit un 'rm -rf $VARIABLE' dans un script qui est censé être lancé en root sur des dizaines de milliers de configs (représentant autant de cas particuliers), bah on fait quelques vérifs autour histoire de s'assurer que $VARIABLE à bien la tronche du chemin attendu. Bon enfin bref, là n'est pas le problème, mon intention n'était vraiment pas de flamer le malheureux auteur de cette boulette, d'autant que c'est vraiment un contributeur majeur de Gentoo et que je le respecte en conséquence. Ce que je voulais juste rappeler, à toute fin utile, c'est que les erreurs innévitablement commises de temps à autres dans les nouveaux ebuilds (ou ce qui y est rattaché) peuvent dépasser le simple bug de compil'.

----------

## PabOu

Juste pour préciser que en plus d'etre ~ARCH, glibc-2.4-r2 est hardmasqué. Peut-être que ca date d'après la découverte du problème en fait...

----------

