Aller au contenu principal
Sujet résolu
Ce sujet a été marqué résolu et ne nécessite aucune autre attention.
Sujet: Gros upgrade TW (20230813) et plus de 400 nouveaux paquets (Lu 6356 fois) sujet précédent - sujet suivant

Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets

Répondre #15
j'ai bien utilisé cette commande pour supprimer lyx. Dans yaST, je ne vois pas de paquets orphelins qui expliqueraient le phénomène.
Une aiguille dans une botte de foin ... c'est tout à fait ça !

Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets

Répondre #16
hello

oui, je partage complètement l'avis général : les mainteneurs qui poussent via des "recommend" des trucs qui leur paraissent "évidents" par rapport à leurs conf perso, c'est une plaie (et les fans de Jupyter ou de haskell ou de latex ou des modules pythons ou etc... ne voient pas pourquoi ils font halluciner les non-développeurs). sans parler des mainteneurs qui gèrent sans finesse les dépendances dans leurs paquets en propageant dans leur rpmspec les versions de ce qu'ils ont en local sur leur machine de bidouille sans même tester sur un host propre avec les versions par défaut : je pense qu'ils ont la palme...



bref, comme chacun y va de ses astuces, je vais ajouter les miennes ;-)


1-
(ignorez si vous n'utilisez pas Calibre)
petite parenthèse pour Calibre : , la recommandation officielle pour installer ... est de ne pas utiliser les versions disponibles dans les distros :
Citer
Merci de ne pas utiliser le paquet calibre fourni par votre distribution, ceux-ci sont souvent problématiques/obsolètes. Utilisez plutôt l'installation des binaires décrite ci-dessous.
(https://calibre-ebook.com/fr_CA/download_linux)

c'est un peu comme utiliser un snap, mais sans snap, en utilisant directement avec la méthode du développeur/mainteneur (qui maîtrise), et en lançant sa méthode one-liner marche du premier coup


2-
(ignorez si vous ne faîtes pas de bricolages python)
le sujet "la version de python du système est trop vieille" est sans fin :
 - j'ai quelques exemples de collègues qui ont fini par casser le système lui-même en voulant modifier le python du système pour essayer de le plier à leurs besoins "user",
 - le "pip --user" en utilisant le python système ne résoud rien aux besoins "user" en général,
 - oser demander aux mainteneurs de la distro (stable) de mettre à jour le python système afin de pour pouvoir installer le dernier truc instable à la mode qui tire des dépendances délirantes, c'est plutôt le monde à l'envers,
 - etc...

bref, j'ai définitivement arrêté d'ajouter les modules python "demandés par les gentils outils de dev que l'on doit installer en permance" en allant à la pêche avec zypper et en complétant avec pip, car au final il y a une pollution inutile du python système

"moins il y a de paquets pythons installés avec zypper et mieux c'est"

ma solution préférée est d'utiliser 'pyenv' pour gérer ma collection de versions de python, sur lesquelles je viens ajouter des modules exotiques avec pip une fois la version choisie grâce à pyenv.  c'est un peu dans le même style que 'rustup' pour gérer plein de versions de rust en parallèle, et surtout : en mode light par rapport à anaconda ou jupyter

il suffit de mettre ces lignes à la fin du .profile/bashrc/etc, et de switcher dans un des contextes python en stock avec "pyenv VERSION" (éventuellement en mettant la commande au début du script qui lance tel ou tel outil qui a besoin de sa version de python)

mais pour faire des tests pour valider qu'un dev python fonctionnera (ou pas) avec les N versions de python potentiellment installées chez tous les utilisateurs, c'est très cool
 
# let PYENV be the default method to manage multiple version of python in a NON-SYSTEM context
PYENV_ROOT="$HOME/.pyenv"
export PYENV_ROOT
command -v pyenv >/dev/null || PATH="$PYENV_ROOT/bin:$PATH" && export PATH
eval "` pyenv init - `"


3-
comme je suis développeur dans la journée et bricoleur à mes heures perdues, j'ai en local sur mes machines une collection "confortable" de 65 repositories qui s'empilent avec des priorités, au dessus (ou au dessous) des repositories de référence, car j'ai souvent besoin d'installer des paquets non-standards sélectionnés par-ci/par-là (je vais à la pêche sur OBS et en général je trouve tout sans avoir besoin de passer par snap ou équivalent), ou tout simplement des version plus sympatiques .que les repositories de référence (ex: KVM/libvirt)

comme ces paquets proviennent de N développeurs/mainteneurs qui bossent chacun dans leur coin, - chacun avec sa conf locale qui lui semble évidente -, c'est un bazar sans fin avec les mises à jour délirantes et/ou les conflits insolubles si on n'a pas les super-pouvoirs de la libzypp à portée de main

l'idée de sélectionner "la pépite dans chacun de ces repos, et d'essayer de tirer uniquement les grappes des dépendances dont ils ont vraiment besoin, en mode "dentelle", grâce aux priorités des repositories, et surtout grâce aux affinités gérées par la libzypp

et surtout avec le solveur de la libzypp qui détecte les problèmes avant la cata, qui propose des solution de repli avec changement d'affinité de tel ou tel paquet sur un autre repo ("vendor-change"), itérativement jusqu'à ce que ça marche, et surtout sans rien casser tant qu'on n'a pas fait YES à la fin.  pour info j'ai définitivement arrêté debian après avoir réussi à faire planter dpkg (ie: perdre la base des paquets installés) en tentant une mise à jour avec stable/testing/unstable simultanés, en pensant que la gestion des versions ferait le job même si les mainteneurs étaient "légers"...

bref, zypper, zypper, et re-zypper

j'ai donc fini par converger vers une méthode un peu non-conventionnelle pour faire mes mises-à jour "de base" (quand le p'tit windget des updates faciles dans le tray est perdu)

"control-R zypper" me fait ressortir tout de suite de l'historique la ligne à rallonge toute prête qui fait tout du sol au plafond et qui permet de faire sortir immédiatement le solveur au moindre doute dans la jungle des repositories (et des mainteneurs) :

zypper refresh && zypper dup  --allow-vendor-change --allow-name-change --allow-arch-change --allow-downgrade --no-recommends 

le temps de calcul du solver n'est pas long (par rapport au temps du refresh de 65 repositories...), et c'est toujours bon du premier coup, car au lieu de faire un update simple qui va faire sortir le solver pour essayer de résoudre itérativement sans trop savoir dans quelle direction on part, le résumé affiché par le dup propose directement le résumé de ce qu'il faudrait faire pour arriver à une nouvelle situation stable

une revue rapide pour détecter un gros loup éventuel (du genre 2000 fichiers et là je creuse), mais sinon c'est OK direct car en général c'est parfait

j'ai des zones de priorité pour les repositories en fonction des types de softs, en laissant les trucs plus stables fournir un socle de référence et en permettant aux trucs les plus volatiles de vivre plus vite (valeur de prio inférieure)
  plus prioritaire (~90)
    - média (pacman, vlc, codecs, etc)
    - langages de dev
    - outils de productivité (git, mercurial, edit, debug)
    - réseau (mozilla, davmail, samba)
    - kde/Qt  (au cas par cas, en faisant super gaffe, et avec "disable + le dup magique" pour réparer au cas où)
    - système (filesystems, vitualisation, monitoring)
    - [les repos opensuse leap et SLE de référence]
    - kernel latest (pour aller à la pêche aux modules propriétaires récents sans tirer un kernel par jour)
    - les trucs expérimentaux en mode ça passe ou ça casse (si le solveur s'affole je n'installe pas et je retourne à la pêche chez OBS)
moins prioritaire (~110)


en général je partage ces trucs avec mes collègues locaux, mais là c'est un post public pour de vrai, et donc j'ai hâte de lire vos retours

eric




Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets

Répondre #17
Tu es développeur, perso je suis utilisatrice plus classique. Installer lyx avec tous les paquets recommandés dont texlive n’a jamais été un problème sur Leap car les mises à jour système sont moins nombreuses, j’ai apprécié d’avoir un logiciel directement fonctionnel pour travailler alors que sur Debian je dois d’abord chercher des paquets à ajouter pour pouvoir réutiliser mes documents.

J’ai opté pour une installation de Lyx avec distrobox car sur Tumbleweed les mises à jour sont très fréquentes et ça fait souvent beaucoup de paquets. Ainsi je maintiens plus facilement le système principal. Mon problème est qu’avant d’adopté cette méthode, j’avais installé Lyx sur le système. Je pense l’avoir supprimé avec toutes ses dépendances et recommandés, il y a sans doute un autre paquet qui recommande texlive. Mais comme celui-ci était installé, ça ne m’a pas sauté aux yeux quand j’ai installé cet autre paquet.

Je suis plutôt à la recherche d’une commande qui permettrait de savoir quels sont les paquets installés sur le système qui recommande un paquet nommé x.

Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets

Répondre #18
Citer
Tu es développeur, perso je suis utilisatrice plus classique. Installer lyx avec tous les paquets recommandés dont texlive n’a jamais été un problème sur Leap car les mises à jour système sont moins nombreuses, j’ai apprécié d’avoir un logiciel directement fonctionnel pour travailler alors que sur Debian je dois d’abord chercher des paquets à ajouter pour pouvoir réutiliser mes documents.

C'est exactement ça, les développeurs openSUSE ont eu raz le bol d'entendre qu'il manquait ceci et cela et du coup ils ont tout mit dans les recommends, facilement évité avec l'option zypper qui va bien. Sous Debian c'est l'inverse, il faut chercher les paquets manquant et parfois c'est chiant. Si on avait été sous arch ou gentoo, on aurait pas eu le choix et on se serait plaint d'avoir un gros et lourd paquet non découpé en plusieurs plus léger qui permettraient de sélectionner ou de retirer juste ceux qui nous intéressent. Etant sur Debian, je trouve l'approche d'openSUSE bien plus sympa, on a un truc qui marche out of the box.

Citer
Je pense l’avoir supprimé avec toutes ses dépendances et recommandés, il y a sans doute un autre paquet qui recommande texlive.

Pure hasard, tu n'aurais pas un truc comme pandoc ou discount, voir un autre truc en rapport avec markdown ou un translate? Mes recommends venaient tous de discount qui demandait texlive...

Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets

Répondre #19
Non je n'ai pas discount. Si j'étais courageuse, je réinstallerais au propre mais ça va attendre ...

Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets

Répondre #20
Pour Calibre, l'avalanche des recommandés est assez récente. Pas de ça sur Leap quand je l'utilisais ni sur TW il y a quelques temps. Tu installais Calibre et Jupyter, Accerciser ou ipython ne montraient pas le bout de leur nez dans le menu des applications (pourquoi faire?).

@loustic : oui, je connais la préconisation du développeur de Calibre. J'ai toujours associé celle-ci au manque de fraîcheur des versions proposées par telle ou telle distribution (c'est un logiciel très fréquemment mis à jour). Avant sur Debian (stable) je passais par les backports pour Calibre. Ceci dit Calibre a toujours bien fonctionné en passant par les dépôts, donc je ne m'inquiétais pas.

Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets

Répondre #21
hello @chalu

J’ai opté pour une installation de Lyx avec distrobox car sur Tumbleweed les mises à jour sont très fréquentes et ça fait souvent beaucoup de paquets.

j'ai aussi texlive sur mon host (pour faire du markdown->pandoc->pdflatex->pdf avec un résultat final propre, sinon le pdf fait peur), et c'est le high-score pour la décomposition extrème en petits paquets:
rpm -qa | grep texlive | wc -l
2746


J’ai opté pour une installation de Lyx avec distrobox car sur Tumbleweed les mises à jour sont très fréquentes et ça fait souvent beaucoup de paquets. Ainsi je maintiens plus facilement le système principal. Mon problème est qu’avant d’adopté cette méthode, j’avais installé Lyx sur le système. Je pense l’avoir supprimé avec toutes ses dépendances et recommandés, il y a sans doute un autre paquet qui recommande texlive. Mais comme celui-ci était installé, ça ne m’a pas sauté aux yeux quand j’ai installé cet autre paquet.

je suis d'accord : le bundle c'est très pratique.  ça vaut peut-être aussi le coup de tenter d'ajouter le repository d'un mainteneur sérieux de lyx avec une priorité plus grande, puis de fixer l'affinité de lyx et ses dépendances sur ce repo (vendor-change).  avec un peu de chance, ce mainteneur n'est pas abonné sur la CI qui lance un build dès qu'un développeur fait un 'git push', le truc qui déclenche une rafale de nouveaux binaires disponibles (ce que malheureusement OBS doit être programmé à faire...)

les distributions homéostatiques comme tumbleweed ou arch, c'est "toujours à jour", mais comme il y a pas mal de développeurs opensource, ça bouge pas mal dans les mises à jour  (c'est pour ça que je fonctionne avec leap + patch en dentelle pour les trucs en plus ou plus récents)


Je suis plutôt à la recherche d’une commande qui permettrait de savoir quels sont les paquets installés sur le système qui recommande un paquet nommé x.

et sinon, pour faire le ménage, ...

la database des paquets installés possède toutes les réponses (c'est un débat sans fin mais il me semble que 'rpm' gagne au niveau des options par rapport à 'dpkg').  il y a l'approche "UI avec yast" en jouant avec les checkbox sur la gauche, ou l'approche copier/coler dans le terminal (qui a l'avantage d'être scriptable)
 
pour voir les infos disponibles sur un paquet donné (infos présentes dans le rpmspec pour la création du paquet avec rpmbuild) :
rpm -q --provides <nom_de_paquet>  --> donne les aliases utilisés dans la base pour les résolutions provides/requires
rpm -q --requires <nom_de_paquet>   --> les alias demandés (le truc qui fait que zypper choisit automatiquement X ou Y)
rpm -q --recommends <nom_de_paquet>  --> les alias suggérés, ... et sélectionnés

pour faire des recherches sur la base et chercher les coupables (exemple en partant de pdflatex) :
rpm -q --whatprovides /usr/bin/pdflatex  -->  texlive-latex-bin-bin-2021.20210325.svn54358-150400.31.3.1.x86_64
rpm -q --provides texlive-latex-bin-bin-2021.20210325.svn54358-150400.31.3.1.x86_64  -->  texlive-latex-bin-bin
rpm -q --requires texlive-latex-bin-bin  -->  texlive-latex-bin
rpm -q --recommends  texlive-latex-bin  -->  {texlive-collection-fontsrecommended, texlive-collection-genericrecommended, texlive-collection-latexrecommended}
rpm -q --requires texlive-latex-bin  -->  texlive
rpm -q --recommends  texlive  -->  texlive-scheme-medium
rpm -q --whatrecommends  texlive  -->  no package recommends texlive
rpm -q --whatrecommends  texlive-scheme-medium  -->  texlive-2021.20210325-150400.31.3.1.x86_64

en général, pour faire le ménage, la méthode qui marche assez bien est :
rpm -e xxx  -->  message d'erreur : xxx is neede by aaa, bbb, ccc

il suffit d'itérer en ajoutant les paquets, ... en sachant s'arrêter à temps (dans la cas où le paquet est une dépendance du système)
rpm -e xxx aaa bbb ccc
rpm -e xxx aaa bbb ccc ddd eee fff

bon, ok, avec texlive et ses 2746 paquets en dépendance, il faut générer la liste avec awk, sinon le copier/coller est fastidieux:
deps=` rpm -e xxx |& awk '{ print $NF}' `
rpm -e texlive $deps  --> c'est là qu'il faut faire attention à ne pas effacer "trop"...

et à la fin, la commande passe...

eric

Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets

Répondre #22
hello @Chumi

@loustic : oui, je connais la préconisation du développeur de Calibre. J'ai toujours associé celle-ci au manque de fraîcheur des versions proposées par telle ou telle distribution (c'est un logiciel très fréquemment mis à jour). Avant sur Debian (stable) je passais par les backports pour Calibre. Ceci dit Calibre a toujours bien fonctionné en passant par les dépôts, donc je ne m'inquiétais pas.

en fait, j'ai basculé sur la méthode du développeur le jour où j'ai tenté d'installer "en insistant" une version de Calibre "récente", en réalité "plus récente que celle du système" (c'était pour faire de la maintenance en local sur le host où se trouve ma collection Callibre, - donc : trop long par le réseau -, et pas de bol ce host méritait quelques 'zypper dup -releasever=X' pour rattraper son retard)

la version récente de Calibre tirait plein de dépendances introuvables et comme j'arrivais pas à tout trouver sur OBS j'ai essayé de faire le build moi-même des morceaux manquants, mais à la fin j'ai arrêté car je suis tombé su run paquet '-devel' qui m'obligeait à toucher au système, et il fallait faire une VM dédiée pour m'en sortir. galère.

et je suis tombé sur ce fameux one-liner qui a marché parfaitement...

si je savais comment fonctionne OBS, je me ferais un compte et mon premier commit serait pour wrapper le one-liner de Calibre ;-)

eric

Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets

Répondre #23
Merci @loustic‍ pour ces commandes. Je testerai la prochaine fois que tous ces paquets voudront s’inviter.

Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets

Répondre #24
@chalu : tu peux rappeler ce lot de paquets à tous moments avec :

sudo zypper dist-upgrade --dry-run --recommends

@loustic : je m'associe à chalu pour te remercier de ton intervention. Un développeur qui met les pieds dans le plat, ce n'est pas de refus, et même si j'ai du mal à tout comprendre, ma lanterne s'éclaire un peu (eh oui! les commandes rpm peuvent aussi servir  ;) )

Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets

Répondre #25
alors si je prends un autre paquet qui veut s'incruster : git-gui
chalu@localhost:~> rpm -q --recommends git-gui 
le paquet git-gui n'est pas installé
chalu@localhost:~> rpm -q --whatrecommends git-gui 
no package recommends git-gui
 
Je comprends que git-gui n'est recommandé par aucun paquet ? Alors pourquoi veut-il s'incruster ?
zypper se -i git
Chargement des données du dépôt...
Lecture des paquets installés...

S  | Name      | Summary                                             | Type
---+-----------+-----------------------------------------------------+-------
i+ | git       | Fast, scalable, distributed revision control system | paquet
i  | git-core  | Core git tools                                      | paquet
i  | git-cvs   | Outil Git pour importer des dépôts CVS              | paquet
i  | git-email | Outil pour envoyer des emails                       | paquet
i  | git-svn   | Git tools for importing Subversion repositories     | paquet
i  | perl-Git  | perl Bindings for Git                               | paquet
Aucun de ces paquets installés ne recommande git-gui. Je ne suis pas douée pour chercher une aiguille dans une botte de foin !

 

Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets

Répondre #26
salut @chalu

en effet c'est une colle, et je suis quand-même allé chercher au plus simple, à savoir regarder ce que recommande git lui-même en ce moment, et la réponse est surprenante...
$ rpm -q --recommends git
git-cvs
git-email
git-svn

et donc ma réponse la plus probable est :
 - tu as sans doute installé git "il y a un certain temps",
 - à cette époque, git-gui était "la référence" pour faire de la UI avec git (mais depuis, comment dire ? ...*),
 - et git-gui aurait donc été installé avec un '--recommends' "avant" ?
 - et depuis, il est mis à jour en silence puisqu'il est présent dans la liste des paquets installés ?
 - (j'ai vérifié sur mes machines et il est présent partout : pareil --> du coup je l'ai viré)
 - (et j'essayerai de voir qui le fait revenir, si il revient)

pas mieux  ::)

eric


*à ce propos,  je cherche des avis pour une UI de git sur linux qui serait "aussi" parfaite que tortoisehg pour mercurial (selon moi)

pour l'instant je reste toujours sur la faim car les UI disponibles sous linux proposent uniquement des fonctions basiques pour le B-A-BA de la vie de développeur, mais quand on veut faire de l'archéologie dans le "bazar" d'un repo git il faut des super pouvoirs que la plupart des UI ne traitent pas, ... ou alors partiellement (ex: GitAhead),  ... ou alors on enrage car bien sûr ça existe sous windows mais ça ne se lance pas avec wine (caramba, encore raté)

bref, si vous avec une idée de perle rare, je prends

et sinon je peux vous partager mon README pour configurer la dernière version de gitExtensions (windows) développée avec la dernière version de .NET supportée par mono, ce qui est pour l'instant "le moins pire" selon moi (avec meld comme compagnon c'est presque parfait)




Re : Gros upgrade TW (20230813) et plus de 400 nouveaux paquets

Répondre #27
git-gui n'est pas ou n'est plus installé sur mon système, mais il veut jouer l'incruste de temps en temps ... lors d'un zypper dup.
comme ce n'est pas à chaque zypper dup, je pensais que c'était lié à un paquet mis à jour mais je ne trouve pas que ce soit pour lui ou les paquets texlive...
Rien de catastrophique puisque dans ce cas je fais la mise à jour sans les recommandés.