| View previous topic :: View next topic |
| Author |
Message |
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
 Posted: Wed Mar 25, 2020 9:25 am Post subject: ACCEPT_KEYWORDS et package.accept_keywords (~arch) |
 |
|
# ACCEPT_KEYWORDS="~amd64" et package.accept_keywords
Bonjour,
Je suis désormais avec ACCEPT_KEYWORDS="~amd64" dans /etc/portage/make.conf pour mon transportable Asus n73sm.
Le contenu de /etc/portage/package.keywords ou /etc/portage/package.keywords/* a dû être mis bien auparavant dans /etc/portage/package.accept_keywords
J'ai effectué la mise à jour @world.
Je me demande quel est l'intérêt désormais des déclarations faites préalablement dans /etc/portage/package.accept_keywords ?
Si ce n'est autrement que de l'archivage à conserver pour éventuellement revenir rapidement en version semi-stable,
puis-je effacer le contenu de /etc/portage/package.accept_keywords ?
Ou bien alors /etc/portage/package.accept_keywords conserve-t'il un rôle ?
Merci
Last edited by pti-rem on Thu Mar 26, 2020 10:32 am; edited 1 time in total |
|
| Back to top |
|
 |
guitou
Guru
Joined: 02 Oct 2003
Posts: 534
Location: France
|
| Posted: Wed Mar 25, 2020 12:39 pm Post subject: |
|
|
Bonjour.
A priori, le contenu de /etc/portage/package.keywords/* est en effet redondant, mais ne devrait aucunement avoir d'incidence (sauf à avoir autre chose que du ~amd64 dans un des fichiers).
Du coup, à toi de voir...
Toutefois, de mémoire je crois que rebasculer d'un système ~arch vers arch n'est ni trivial ni recommandé, donc pas sûr que ce soit d'une grande utilité de le garder.
++
Gi) |
|
| Back to top |
|
|
ghoti
Advocate
Joined: 30 Dec 2002
Posts: 3634
Location: Belgium
|
| Posted: Wed Mar 25, 2020 1:21 pm Post subject: |
|
|
| guitou wrote: | | Toutefois, de mémoire je crois que rebasculer d'un système ~arch vers arch n'est ni trivial ni recommandé, donc pas sûr que ce soit d'une grande utilité de le garder. |
Bonjour,
S'il est vrai que rebasculer de ~arch vers arch n'est pas une mince affaire, on peut toutefois souhaiter forcer certains paquets individuels en arch pour diverses raisons, par exemple,
- paquets sensibles pour lesquels la stabilité est cruciale
- paquets fréquemment mis à jour mais dont la compilation est interminable
- paquets qui entraînent la recompilation de nombreux autres gros paquets sans que le bénéfice soit forcément évident
- ...
Il peut également exister dans certains overlays, des ebuilds expérimentaux "invisibles" parce que le KEYWORDS est vide (""). Le fichier package.accept_keywords permet de le rendre malgré tout visible ("**") sans devoir tripoter l'ebuild. |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Thu Mar 26, 2020 10:29 am Post subject: |
|
|
Merci pour vos réponses.
| ghoti wrote: | | il est vrai que rebasculer de ~arch vers arch n'est pas une mince affaire |
Je ne m'attendais pas à ça ! J'en avais pas conscience.
Ma mise à jour a été périlleuse et je crois que je me suis fait avoir par le simple app-eselect/eselect-opengl qui aurait dû être effacé avant.
Je sens ma Gentoo comme un château de cartes maintenant... et si je trouve la motivation et le temps, je réinstallerai en arch.
| ghoti wrote: | | on peut toutefois souhaiter forcer certains paquets individuels en arch |
Merci de donner un exemple ou deux pour /etc/portage/package.accept_keywords 
Doit-on conjuguer avec /etc/portage/package.mask ?
| ghoti wrote: | pour diverses raisons, par exemple,
- paquets sensibles pour lesquels la stabilité est cruciale |
C'est un bon commencement mais d'une, je n'ai pas idée de la liste minimale commune qui pourrait être adoptée,
et de deux, quand un des paquets considérés est déjà en ~arch, comment le faire revenir en arch sans galérer en mode majeur ?
C'est donc à faire le plus tôt possible ?
Et est-il réellement possible d'en faire une petite liste « sensibles-stabilité-cruciale »? |
|
| Back to top |
|
|
sebB
l33t
Joined: 02 Mar 2011
Posts: 806
Location: S.O. France
|
| Posted: Thu Mar 26, 2020 12:17 pm Post subject: |
|
|
Il doit être possible de "figer" ton système.
Déjà te demander si ton système est fonctionnel.
Tu crée un package.accept_keywords ou tu mets l'ensemble de tes logiciels installés avec leur version (=xxx/yyy-123).
Dans ton make.conf tu rebascule en stable.
Et tu laisse le temps faire au fil des maj. |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Thu Mar 26, 2020 12:47 pm Post subject: |
|
|
Je sais faire la liste des logiciels installés pour créer un package.accept_keywords de gel
| Code: | | equery list -F '=$cpv::$repo' '*' |
Il n'y a pas besoin de rajouter ~amd64 ou amd64 en fin de ligne de chaque paquet.
Je ne vais pas tester tous les logiciels mais mon système se comporte normalement jusqu'à présent.
Merci bien sebB ! Cela semble facile comme tu l'indiques.
Une première mise à jour s'est bien passée, avec un downgrade d'un paquet ~arch.
Je pense en faire plus régulièrement, genre hebdomadaire maxi. |
|
| Back to top |
|
|
sebB
l33t
Joined: 02 Mar 2011
Posts: 806
Location: S.O. France
|
| Posted: Thu Mar 26, 2020 3:00 pm Post subject: |
|
|
Ah oui, je ne pensai pas que tu le ferai 
Ca ne va pas être aussi simple que ça car il va falloir aussi que tu surveille les paquets et dépendances obsoletes.
Gentoo est assez conservateur sur les ebuild mais portage risque de ne pas être content si par ex tu as figé foo-r1 et qu'il n'existe plus étant remplacé par foo-r2.
Ou alors il faudrait que tu clone l'arbre gentoo de ce jour dans un overlay perso.
| Quote: | | Une première mise à jour s'est bien passée, avec un downgrade d'un paquet ~arch. |
Voici un exemple de ce qui n'est pas normal. Perso je ne ferai pas de downgrade mais jouerai sur le accept.keyword.
C'est quel paquet et quelle version tu avait avant et maintenant? |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Thu Mar 26, 2020 3:39 pm Post subject: |
|
|
C'est thunar qui a été downgradé de 1.8.14 unstable à 1.8.12 stable
https://packages.gentoo.org/packages/xfce-base/thunar
| sebB wrote: | | Perso je ne ferai pas de downgrade mais jouerai sur le accept.keyword |
J'ai comme l'impression qu'il va y avoir du cas par cas.
Je ne suis pas en situation de me permettre de jouer à l'escalade avec des ajouts ~arch systématiques.
Portage propose d'ajouter lui-même quand c'est nécessaire.
| sebB wrote: | | portage risque de ne pas être content si par ex tu as figé foo-r1 et qu'il n'existe plus étant remplacé par foo-r2 |
Je ne crois pas qu'une mention restante dans package.accept_keywords d'un paquet devenu inexistant soit problématique.
J'avais "des tonnes" d'entrées inutiles dans ce fichier avant de passer en ~amd64 et ma Gentoo ne s'en plaignait pas.
Par "figé", j'entends juste mentionné dans package.accept_keywords, sous la forme =xxx/yyy-1.2.3::repository
J'imagine que Portage continuera de m'indiquer quels paquets y ajouter si c'est nécessaire.
Je reste en stable mais avec certains paquets en ~arch. Enfin, c'est mon souhait.
Ce qui est bizarre, c'est que Portage me donnait à y ajouter des paquets mais en mettant ~amd64 en fin de ligne ;
Alors que le package.accept_keywords que j'ai constitué n'en contient aucun et ça semble ne pas le déranger : ça fonctionne tout autant.
| sebB wrote: | | Ou alors il faudrait que tu clone l'arbre gentoo de ce jour dans un overlay perso |
C'est une blague j'espère ! Pourvu que je n'ai pas cette complication à envisager.
| sebB wrote: | | il va falloir aussi que tu surveille les paquets et dépendances obsolètes |
Oui, je veux bien... en pratique, je ne vois pas encore où ça va coincer...
C'est l'étape emerge -av --depclean qui s'en charge, non ?
Dès que se posera un problème lors d'une mise à jour, j'ouvrirai un sujet dédié.
Je ne suis pas sûr de pouvoir comprendre une explication théorique, dsl.
Tu peux essayer de m'exposer un raisonnement et j'essaierai de le comprendre.
Oui, je tente ma chance |
|
| Back to top |
|
|
sebB
l33t
Joined: 02 Mar 2011
Posts: 806
Location: S.O. France
|
| Posted: Thu Mar 26, 2020 4:11 pm Post subject: |
|
|
On va dire que tu as le paquet toto installé en version instable.
Tu as toto2 instable qui dépends du paquet instable >= foo-2-r1.
toto1 stable qui dépends du paquet stable = foo-1
foo existe donc dans portage en version foo-1 (stable), foo-2-r1 (instable).
Gentoo décide de supprimer foo-2-r1 de l'arbre et d'inclure à la place foo-2-r2 (instable)
A la prochaine maj tu aura un problème car toto2 instable dépendra de foo-2-r2 instable qui n'est pas ton keyword donc il va vouloir te downgrader foo en stable ce qui va entrainer le downgrade de toto1 en stable et ainsi de suite.
Et ca marche aussi si c'est toto2 qui est supprimé et remplacé par toto3 instable. Portage va vouloir installer toto1 puis foo-1 puis ...
Par le jeu des dépendances, ca va vite devenir bloquant si tu n'est pas vigilant.
Le but étant d'éviter les downgrade, donc jouer avec le package.keyword un bon moment encore (dans ce cas remplacer foo-2-r1 par foo-2-r2).
Il faut que, soit tes paquets instables deviennent stable, soit qu'une version stable supérieure arrive.
Concernant les maj, il faudrait au contraire les faire plus régulièrement, les conflits seront plus visibles.
Mais si tu veux tenter l'expérience... |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Thu Mar 26, 2020 4:34 pm Post subject: |
|
|
| sebB wrote: | | Concernant les maj, au contraire, plus elles seront fréquentes moins tu aura de conflits. |
Là je suis bien d'accord avec toi ; je ne pense pas avoir dit autrement.
Je vais les faire tous les jours si il le faut.
| sebB wrote: | | Il faut que, soit tes paquets instables deviennent stable, soit qu'une version stable supérieure arrive. |
Je comprends mieux avec cette phrase. Merci
J'avais imaginé une logique inverse, rendre stable en downgradant autant que possible.
Maintenant, lumière est faite.
| sebB wrote: | Par le jeu des dépendances, ca va vite devenir bloquant si tu n'est pas vigilant.
Le but étant d'éviter les downgrade, donc jouer avec le package.keyword un bon moment encore |
Ça va pas être drôle ce jeu pour chaque downgrade proposé... et pour « un sacré bon moment encore » !
Autant prendre l'habitude et le réflexe, j'ai donc inclus thunar en version 1.8.14 unstable dans package.accept_keywords.
Il me faut un tout petit script pour me faciliter la tâche. |
|
| Back to top |
|
|
sebB
l33t
Joined: 02 Mar 2011
Posts: 806
Location: S.O. France
|
| Posted: Fri Mar 27, 2020 3:07 pm Post subject: |
|
|
| Quote: | | Ça va pas être drôle ce jeu pour chaque downgrade proposé... et pour « un sacré bon moment encore » ! |
C'est pourquoi je t'ai proposé de cloner l'arbre gentoo dans un overlay perso sur ton système. C'est arbre sera figé à ton système actuel.
En faisant ca, même si gentoo décide de supprimer un paquet de l'arbre principal tu l'aura toujours à dispo dans ton overlay et ainsi tu évite tout les conflits.
Tu pourra ainsi continuer à synchroniser l'arbre principal et faire tes maj à la fréquence que tu veux. Ca m'étonnerai que tu en ai pendant un petit / grand moment.
Y'aura juste à vérifier les CVE si tes paquets figés sont impactés.
Je ne sais pas si on verra le résultat de notre vivant,.. |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Fri Mar 27, 2020 11:31 pm Post subject: |
|
|
J'ai fait ça :
| Code: | n73sm /opt # git clone https://anongit.gentoo.org/git/repo/gentoo.git
Clonage dans 'gentoo'...
remote: Enumerating objects: 12713, done.
remote: Counting objects: 100% (12713/12713), done.
remote: Compressing objects: 100% (10374/10374), done.
remote: Total 2257650 (delta 5149), reused 5075 (delta 2338)
Réception d'objets: 100% (2257650/2257650), 571.07 Mio | 2.08 Mio/s, fait.
Résolution des deltas: 100% (1584431/1584431), fait.
Mise à jour des fichiers: 100% (89889/89889), fait.
n73sm /opt # date
ven. mars 27 23:11:03 CET 2020
n73sm /opt # mv gentoo gentoo-2020 |
Je ne sais pas en faire un overlay perso sur mon système.
Il faut que je déclare /opt/gentoo-2020 dans un /etc/portage/repos.conf/gentoo-2020.conf ?
J'ai fait un petit essai :
| Code: | n73sm ~ # cat /etc/portage/repos.conf/gentoo-2020.conf
[gentoo-2020]
location = /opt/gentoo-2020
auto-sync = no
masters = gentoo
priority = -2000
# pour donner la priorité au repository gentoo officiel
n73sm ~ # |
Et alors eix-sync -a est très lent et me retourne plusieurs : « !!! Section 'gentoo-2020' in repos.conf has name different from repository name 'gentoo' set inside repository »
J'ai déjà une section [gentoo] :
| Code: | n73sm ~ # cat /etc/portage/repos.conf/gentoo.conf
[DEFAULT]
main-repo = gentoo
[gentoo]
location = /usr/portage
sync-type = rsync
sync-uri = rsync://rsync.fr.gentoo.org/gentoo-portage
auto-sync = yes
# for daily squashfs snapshots
#sync-type = squashdelta
#sync-uri = mirror://gentoo/../snapshots/squashfs
n73sm ~ # |
| sebB wrote: | | Y'aura juste à vérifier les CVE si tes paquets figés sont impactés. |
Oui, d'accord... Je ne sais pas faire encore.
Et ils sont vraiment nombreux les paquets figés ; ils le sont tous en fait.
Last edited by pti-rem on Sun Mar 29, 2020 12:53 pm; edited 8 times in total |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Sat Mar 28, 2020 12:00 am Post subject: |
|
|
J'ai trouvé https://wiki.gentoo.org/wiki/Repository_format qui m'a aidé pour modifier la valeur de /opt/gentoo-2020/profiles/repo_name (de « gentoo » à « gentoo-2020 »)
Le « Building database (/var/cache/eix/portage.eix)... » est très lent pour « "gentoo-2020" /opt/gentoo-2020 (cache: parse|ebuild*#metadata-md5#metadata-flat#assign) »
J'espère que c'est uniquement pour la première passe.
édition : Pour le moment, ça met une heure à chaque fois...
édition 2 : Il me semble que je m'en sors avec :
| Code: | | /usr/bin/eix-sync -o -x\ gentoo-2020 |
| un dry run: | n73sm ~ # /usr/bin/eix-sync -n -o -x\ gentoo-2020
* Running emerge --sync
* Copying old database to /var/cache/eix/previous.eix
* Running eix-update -x gentoo-2020
* Calling eix-diff
n73sm ~ # |
édition 3 : L'option -o de eix-sync pour passer -x gentoo-2020 à eix-update ne fonctionne pas.
Alors, je choisis de faire une par une dans un script les étapes préalables à une mise à jour :
| Code: | # Synchro des overlays
/usr/bin/layman -S
# Running emerge --sync
/usr/bin/emerge --sync
# Copying old database to /var/cache/eix/previous.eix
/bin/cp -a /var/cache/eix/portage.eix /var/cache/eix/previous.eix
# Running eix-update # -x gentoo-2020 # exclusion du repository local gentoo-2020 : plus nécessaire après le 'egencache --repo=gentoo-2020 --update'
/usr/bin/eix-update
# Calling eix-diff # le différentiel est affiché comme d'habitude ; pour autant qu'il y en ait un.
/usr/bin/eix-diff |
Mon overlay local est désormais renommé en « g20 » : c'est plus court.
| sebB wrote: | | Mais si tu veux tenter l'expérience... |
L'actualité de mon expérience personnelle continue dans Rebasculer de ~arch vers arch (sans ACCEPT_KEYWORDS).
Je te remercie grandement pour ton aide sebB !
C'est clair que d'avoir à disposition cet overlay local ne peut que m'aider.
Je ne détiens pas bien les tenants et les aboutissants à l'heure actuelle mais l'expérience est vraiment très enrichissante. |
|
| Back to top |
|
|
|
French
