Forum Linux.redhat substituer un paquet de Red Hat Software Collection au paquet «normal»

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
0
10
mai
2022

Je ne comprend pas bien la doc des Red Hat Software Collection, quand à l'utilisation d'une scl à la place d'un paquet normal.

Pour utiliser nodejs en version 6 sur une Centos 7, je dois ajouter la software collection rh-nodejs6. Il faut nodejs6 pour lire des fichiers CSS écrits avec Lesscss. Ces fichiers sont incompatibles avec des versions plus récentes de Lesscss, et les versions anciennes de Lesscss sont incompatibles avec les versions plus récentes de nodejs. Le bazar habituel.

Donc on installe la software collection rh-nodejs6. Bien. Et maintenant ?

use the Software Collection packages as if they were conventional RPM packages

RedHat explique qu'on peut mettre en place des Syspath pour utiliser directement nodejs6, mais je ne comprend pas comment.

D'autre part, nodejs-1:16 est aussi installé en «normal» à cause de dépendances. Pas besoin de cette version, mais on ne dois pas l'enlever à cause de dépendances.

  • # un depot comme un autre

    Posté par  . Évalué à 4.

    en fait les "collections" sont des dépôts comme les autres, mais restreint autre d'une thématique

    donc une fois que tu as installé (configuré) le depot rh-nodejs6
    il te faut installer les paquets dont tu as besoin

    c'est exactement ce que te dit la doc

    use the Software Collection packages as if they were conventional RPM packages

    reste les problèmes de dépendances pour enlever ou surcharger l'autre paquet

    je dirais que rien n'empêche d'avoir 2 paquets de version différentes s'ils ss'installent chacun dans leur dossier

    à toi ensuite de pointer au bon endroit quand tu veux utiliser nodejs

    • [^] # Re: un depot comme un autre

      Posté par  . Évalué à 2.

      Merci. Le souci c'est de pouvoir pointer au bon endroit avec un logiciel existant (Odoo en l'occurrence). J'ai mieux compris comment ça marche (voir plus bas) mais je me demande si c'est très efficace.

  • # Activation

    Posté par  (Mastodon) . Évalué à 2.

    Les logiciels installés via les Software Collections apparaissent ensuite dans /opt

    Il est souvent nécessaire de mettre en place des variables d'environnements pour surcharger les versions habituelles des dépôts. Pour cela il est nécessaire de charger un fichier d'environnement, par exemple avec

    scl enable rh-nodejs6 bash

    Cette commande va ouvrir un nouveau shell bash avec les bonnes variables d'environnement mises en place.

    • [^] # Re: Activation

      Posté par  . Évalué à 2.

      Merci de ta réponse.
      Mais si je me déconnecte, ça ferme le nouveau shell donc l'accès a la Software Collection. Or c'est un serveur, il faut accéder à nodejs6 en permanence.

      J'ai trouvé des paquets "syspath" pour mariadb qui sont remplis de scripts shells qui positionnent les variables d'environnement. Il faut faire l'équivalent pour nodejs6 ? C'est pas trop lourd d'ouvrir des sous shells à chaque appel de nodejs6?

      Je viens de lire aussi que syspath se trouve fréquemment en conflit avec les fichiers installés par un RPM hors Software Collection.

      • [^] # Re: Activation

        Posté par  (Mastodon) . Évalué à 1.

        Selon le besoin tu dois pouvoir utiliser directement le binaire de nodejs qui se trouve dans /opt.

        Sinon tu dois pouvoir charger les variables d'env dans un script en utilisant un truc du style : . /opt/rh/rh-nodejs6/enable (c'est à adapter, ça doit ressembler).

        • [^] # Re: Activation

          Posté par  . Évalué à 2.

          tu dois pouvoir charger les variables d'env dans un script

          C'est ce que font les scripts dans les paquets dits "syspath". Par exemple avec le serveur de Mariadb.

          La doc étant peu disert à ce sujet, je signale que le paquet scl-utils-build-helpers contient un utilitaire pour produire les scripts "syspath" à l'empaquetage.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.