Red Hat Software Collections 2.1

Posté par  (site web personnel, Mastodon) . Édité par BAud, Nÿco, Benoît Sibaud et ZeroHeure. Modéré par Ontologia. Licence CC By‑SA.
Étiquettes :
14
30
nov.
2015
Red Hat

Red Hat a annoncé, le 17 novembre 2015, les « Software Collections » en version 2.1. Il s'agit d'un canal (terminologie de Red Hat pour désigner un dépôt logiciel) contenant des logiciels aux versions plus récentes que dans les canaux habituels de la distribution RHEL. Une variante communautaire de ce canal est aussi disponible sur le site Software Collections.

Côté développeurs

Jamais deux sans trois, ouvrons cette rubrique par le Red Hat Developer Toolset, qui passe en version 4.0. Les évolutions de cette nouvelle version sont :

  • Eclipse en version 4.5.0 ;
  • GCC en version 5.2.1 ;
  • binutils en version 2.25 ;
  • elfutils en version 0.163 ;
  • dwz en version 0.12 ;
  • GDB en version 7.10 ;
  • strace en version 4.10 ;
  • SystemTap en version 2.8 ;
  • OProfile en version 1.1.0.

Red Hat ne change rien non plus pour les notes de versions, disponibles séparément des notes des Software Collections (en lien de dépêche).

Quelques nouveautés tout de même, avec l'apparition pour RHEL 7 d'un paquet devtoolset-4-dockerfiles. Il contient des fichiers dockerfile, qui peuvent être utilisés pour déployer les composants sus-cités. Les dockerfile suivants sont présent :

  • devtoolset-4-dyninst ;
  • devtoolset-4-elfutils ;
  • devtoolset-4-oprofile ;
  • devtoolset-4-systemtap ;
  • devtoolset-4-toolchain ;
  • devtoolset-4-valgrind.

Ces dockerfiles fournissent un conteneur RHEL 6 ou RHEL 7, sauf devtoolset-4-systemtap qui n'est disponible qu'en conteneur RHEL 7.

Côté serveurs

Pour cette version, les nouveautés ne sont pas nombreuses, mais elles sont de taille : Nginx est maintenant disponible en version 1.8.0 (la 1.6.2 est toujours accessible), et Varnish fait son apparition en version 4.0.3 !

De manière plus discrète, Node.js passe en version 0.10.40, accompagné d'une version de V8 compatible.

Côté langages

Est-ce que cela bouge un peu plus côté langage ? Pas vraiment, seul Java est réellement concerné par cette nouvelle version des Software Collections. Ainsi, rh-java-common apporte deux nouveaux paquets :

  • rh-java-common-apache-commons-jxpath, qui inclut un interpréteur XPath ;
  • rh-java-common-apache-commons-el, qui apporte un interpréteur pour le JSP 2.0 Expression Language.

En supplément, rh-java-common-ecj a été mis à jour en 4.4.2, afin de pouvoir compiler du code Java 8. Par contre, rh-java-common-tomcat-lib ne fait plus partie de la collection, Red Hat annonçant une « impossibilité de le maintenir à jour avec les derniers correctifs de sécurité ».

Aller plus loin

  • # modules

    Posté par  (site web personnel) . Évalué à 2.

    Je n'ai pas de Red-Hat sous la main pour faire le moindre test. La commande 'scl' fonctionne comment ? Elle me semble faire plus ou moins la même chose que la commande 'module' : http://modules.sourceforge.net/

    Quel est l'apport de scl versus module ?

    • [^] # Re: modules

      Posté par  (site web personnel) . Évalué à 2.

      Personnellement j'utilise scl enable devtoolset-2 sh mais effectivement le fonctionnement de scl semble très ressemblant au fonctionnement de modules.

      Un différence notable est que modules est implémenté en TCL alors que scl semble être du C. Sans doute plus simple à distribuer ?

      • [^] # Re: modules

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        C'est probable. On remarquera aussi que d'après la page mentionnée pour modules, celui-ci n'a pas bougé depuis 2012. Peut-être qu'il n'y a pas eu besoin de modifier le code source, mais cela ne me rassure pas spécialement.

        • [^] # Re: modules

          Posté par  (site web personnel) . Évalué à 2.

          En pratique, tu ne fais que modifier à la volée des variables d'environnement via un mécanisme assez simple, une première commande génère un fichier temporaire puis tu source celui-ci dans le shell en cours. Pas besoin de dbus et autre subtilité pour faire cela donc le code doit être robuste avec une API simple.

          Pourquoi un code stable devrait être moins rassurant ;-)

          PS : L'approche module n'est pas parfaite car le unload n'est pas fiable à 100% mais c'est un choix de faire simple. Surtout qu'on ne fait pas en pratique des load/unload toutes les 5min…

          PPS : Il existe d'autres approches comme 'schroot' par exemple. Chaque approche a des avantages et des inconvénients.

      • [^] # Re: modules

        Posté par  (site web personnel) . Évalué à 2.

        Il y a eu une version de modules en 100% C mais qui n'a pas été jusqu'au bout. Ceci dis, je ne pense pas que cela soit un problème pour Red-Hat de modifier modules pour virer la dépendance à TCL ;-)

        L'avantage et l'inconvénient de TCL est que les fichiers de configuration de modules sont en TCL donc tu peux y utiliser toute la puissance de TCL. Comme TCL n'est pas forcément le langage préféré de tous… A mon sens, il serait pas mal de basculer de TCL à LUA qui me semble plus adapté à cet usage.

    • [^] # Re: modules

      Posté par  . Évalué à 3.

      Les Software Collections c'est un peu plus large que Modules, puisque ça concerne également le packaging des libs et applicatifs. Normalement avec quelques macros, tu peux générer avec le paquet sources, des paquets binaires pour ta distro et ta SCL (il suffit d'avoir le paquet d'installé dans ton système de build).

      En bref, l'intérêt des SCL c'est leur intégration poussée aux distros RPM

      • [^] # Re: modules

        Posté par  (site web personnel) . Évalué à 2.

        Comment SCL s'en sors avec les chemins, surtout dans les Makefile avec les include et les bibliothèques à compiler type les options -I et -L de gcc ? Avec modules, je m'en sors en créant des variables non standard (car il n'y a pas à ma connaissance de variable standard pour cela).

        • [^] # Re: modules

          Posté par  . Évalué à 2.

          C'est surtout fait pour fournir des piles applicatives. Si ton application utilise autotools, CMake ou tout autre système de construction supporté, les SCL fournissent des macros RPM pour passer les bonnes infos à celui-ci. Si tu fournis ton application sous forme de paquets RPM, tu as très peu de choses à faire, sinon, pareil qu'avant.

          Pendant que j'y suis une présentation de Remi Collet sur les SCL pour expliquer le concept.
          https://www.youtube.com/watch?v=wj9LrVcGJd4

Suivre le flux des commentaires

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