Journal Dynamic Software Collection

Posté par  .
Étiquettes : aucune
10
7
fév.
2012

Un nouveau projet je crois qui est en cours de développement par Red Hat :

http://jnovy.fedorapeople.org/scl-utils/dsc.pp.pdf

C'est une méthode pour avoir plusieurs logiciels avec des versions différentes (si j'ai bien compris).

Un exemple pour Perl (http://mmaslano.livejournal.com/6685.html) :

Sur RH ils ont la version 5.10 me semble-t-il.
Si vous voulez tester la 5.14.2 sans risque :
> yum install scl_perl514

Pour exécuter ce nouveau perl il y deux possibilités :
> scl enable perl514 'perl'

ou bien :
> scl enable perl514 'bash'
> perl

(La première commande nous fait rentrer dans une nouvelle session ou perl sera par défaut le 5.14).
Sur le blog cité l'exemple n'est pas tout à fait le même, j'extrapôle un peu.

Ca ne marche pas que pour un logiciel mais aussi pour collection de logiciels, exemple avec une "stack" rail qui inclut ruby 1.9.3 avec rail 3.0 : http://mmaslano.livejournal.com/6963.html (dans cet exemple elle préfixe par "stack" : yum install stack_rails_3.0, je sais pas quel est la différence avec "scl").
Et aussi il est expliqué comment modifier les fichiers .specs des RPM existants pour les convertir dans ce système.

Il n'y a pas vraiment d'annonce j'ai trouvé ça par hasard sur une liste de diffusion de Fedora.

  • # /opt

    Posté par  . Évalué à 3. Dernière modification le 07 février 2012 à 23:42.

    Ah oui j'ai oublié de préciser le plus "marrant" (polémique avec le FHS etc..., lire la mailing list ça commence là : http://lists.fedoraproject.org/pipermail/devel/2012-February/162240.html ) :

    Ces collections sont installés dans /opt (/opt/rh/nom_de_la_collection), exemple /opt/rh/perl514.

    Ben oui le FHS prévoit un /opt/provider, je pensais qu'il prévoyait seulement des /opt/package. C'est plutôt bien pensé.

    Je me demande si Debian ne mettrait pas plutôt tout ça dans un /usr/lib/dsc ?

    • [^] # Re: /opt

      Posté par  (Mastodon) . Évalué à 2. Dernière modification le 08 février 2012 à 11:04.

      \o/ wow \o/
      Sinon le nommage est zarb, vous trouvez pas ? Il faut utiliser %_root_bindir par exemple. Dommage qu'ils n'aient pas choisi un %_dsc_bindir, simplement.
      Merci pour cette nouvelle :-)) yeaaaah

      [edit] oupss lecture trop rapide. En fait c'est clair. %root correspond bien à l'usage de macro en dehors de dsc. Nickel. Génial.

  • # C'est marrant on utilise déjà...

    Posté par  . Évalué à 1.

    Hello,

    c'est marrant, mon collègue à développé exactement la même chose:
    tu as une commande pour lancer un outil avec une version spécifique et une autre commande qui permet un regroupement de plusieurs outils de versions choisies. Cela nous permet de pouvoir disposer d'environnement de développement avec une liste de dépendance d'outils longue comme le bras (scl et stack).
    La seul différence c'est que c'est pas basé sur rpm, on compile tout dans dans un répertoire centralisé partagé par nfs de plus, il est assez difficile de gérer les stacks de manière automatisée, car cela dépend dans quel "département" l'utilisteur.
    En tout cas, c'est génial comme système, chapeau à mon collègue ;)

    @+

  • # stow

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

    Il existe déjà depuis longtemps un projet gnu : stow qui permet de gérer plusieurs installation parallèles.

    L'intérêt de ce nouveau logiciel, c'est de gérer des rpm, qui malheureusement doivent être modifiés : je ne vois pas très bien ce que ça apporte par rapport une installation du type
    rpm -Uvh --relocate ...

    • [^] # Re: stow

      Posté par  . Évalué à 3.

      Dans le même style que stow, il y aussi les "alternatives" chez debian. Par contre, la solution dont parle le journal propose une autre friture : la portée de la modification opérée par dsc a l'air limitée au processus invoqué (et à ses enfants, probablement). C'est bien pour, par exemple, tester un truc avec perl 42 pendant que le reste du système continue d'utiliser perl "dernière version stable".

    • [^] # Re: stow

      Posté par  . Évalué à 1.

      J'ai pris un mauvais exemple.
      Ca permet d'avoir un ensemble cohérent de logiciels.
      Par exemple, si une distribution a Gimp 2.6 et gtk 2.21, et qu'elle veut proposer Gimp 2.8 qui ne compile qu'avec gtk >= 2.24 (j'en sais rien si c'est le cas, c'est un exemple), il y aura quelque chose comme ça :

      /opt/rh/gimp28/root/usr/bin/gimp (binaire de Gimp 2.8)
      /opt/rh/gimp28/root/usr/lib/libgtk-2.0.so (bibliothèque de Gtk 2.24)

      C'est une sorte de "bundle" j'ai l'impression.

  • # Not invented here?

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

    Dans le même genre, il y a nix qui semble être le gestionnaire de paquets ultime (multi-versions, multiutilisateurs, multienvironnements...):

    http://nixos.org/nix/

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Suivre le flux des commentaires

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