Sortie de HomeLinux, version 1.0.0

Posté par  (site web personnel) . Édité par Benoît Sibaud, Nÿco, palm123 et ZeroHeure. Modéré par Benoît Sibaud. Licence CC By‑SA.
Étiquettes :
27
5
jan.
2016
Distribution

HomeLinux est un gestionnaire de paquets sources similaire à Gentoo, mais, pour gérer un prefix dans son dossier personnel (donc d'avoir une arborescence alternative). Le but est de télécharger automatiquement la dernière version du paquet demandé et d'installer automatiquement les dépendances si HomeLinux dispose de l'information. HomeLinux peut simplifier la vie d'un développeur ayant besoin des dernières versions d'un paquet ou aider à être à jour lorsque l'on travaille dans un environnement sur lequel on n'est pas administrateur (comme une station de travail dans un laboratoire). Il peut également aider à mettre en place les dépendances dans des environnements de tests gérés par exemple par Jenkins.

Un gestionnaire de paquet pour son dossier personnel

L'approche retenue est similaire à Gentoo prefix mais en tenant compte des paquets systèmes pour tronquer l'arbre de dépendance. On évite ainsi le bootstrapping. HomeLinux ne cherche pas à reconnaitre les paquets stables ou instables et se concentre sur la fourniture des dernières versions publiées ou les versions demandées par l'utilisateur. Il croise sa propre base de données avec celle de Gentoo de sorte qu'il accède déjà à un grand nombre de paquets qu'il tente d'installer avec une méthode automatique. HomeLinux fournit aussi ses propres descriptifs de paquets, mais pour la version 1.0.0 la base est limitée à une centaine de paquets, elle sera améliorée dans les prochaines versions s'il y a des intéressés.

L'origine

Le projet est initialement né lors de mes travaux de thèse en HPC. Sur les clusters, on a souvent besoin d'installer des dépendances de notre projet. Gérer ce prefix est consommateur de temps surtout lorsque l'on veut le mettre au propre puisqu'il faut recommencer toute la procédure : chercher la dernière version sur le web, l'extraire, configurer, se rendre compte qu'il manque une dépendance et cycler ainsi jusqu'à avoir l'ensemble des paquets installés. Grâce à HomeLinux on ne fait le travail qu'une fois en complétant au fur et à mesure la base de données de dépendance, de sorte qu'il est facile de reconstruire un prefix si on veut repartir de zéro. Même sans la liste de dépendance on procède simplement en ajoutant les noms de paquet à la commande au fur et à mesure que les paquets nous les demandent.

Héritage de prefix

HomeLinux peut aussi aider les administrateurs de clusters en fournissant des prefix à jour. HomeLinux permet en effet à un prefix utilisateur d'hériter de prefix existants. L'utilisateur dispose donc des paquets installés par l'administrateur en plus des siens, le tout gérer par le même gestionnaire de paquet. Il est ensuite simple de migrer vers de nouvelles versions de prefix si l'administrateur en crée un nouveau dans un nouveau dossier.

Il s'agit d'une première version depuis la ré-écriture au propre en NodeJS depuis bash, il y a donc bien sûr des choses à améliorer.

Exemple d'utilisation

    #provide environnement variables
    hl env

    #update your package DB (fetch gentoo...)
    hl update-db

    #install package
    hl install bash                      # use name, automatic search db
    hl install app-shells/bash           # force subdir in gentoo way
    hl install gentoo/htop               # use the gentoo archive (nodeps)
    hl install github/ofiwg/libfabric    # from github repos, use last release
    hl install urls/htop                 # Use from packages/urls.lst

    #for non HL packages (gentooo, github...) you can provide some deps
    #infos and conf options into homelinux/packages/quickpackages/, see examples.

    #you can force the vesion to install with
    hl install htop=4.8   #exact version
    hl install htop<4.8   #less than
    hl install htop<=4.8  #less eq than
    hl install 'htop!4.8' #not this one
    hl install htop~4.8   #regexp allow all 4.8.X, take last avail
    hl install htop:4     #slot based

    #search in avail packages
    hl search htop

    #list installed packages
    hl ls

    #uninstall htop (only if you enable stow support in prefix config)
    hl uninstall htop

Aller plus loin

  • # intégration avec d'autres gestionnaires

    Posté par  . Évalué à 4.

    Je trouve ce projet très intéressant, j'aime beaucoup la finalité !

    Une petite question que je me pose cependant : pourquoi ne pas intégrer ceci à un gestionnaire de paquets déjà existant ? Après tout la partie « gestionnaire de paquets » avec ce que ça implique de gestion de dépendances, de maintenance (…), ça existe déjà depuis longtemps (apt, yum, pkg, pkgsrc, pacman…). Avoir cette possibilité directement dans les gestionnaires de paquets habituel serait un gros point positif : on mutualise le travail des mainteneurs, on factorise très fortement le code, presque tous les paquets déjà fait pourraient fonctionner presque sans effort en userspace…

    • [^] # Re: intégration avec d'autres gestionnaires

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

      Cela pourrais être intéressant, la question est à creuser. Je crois qu'il y a de choses possible avec les SRPM pour builder pour un autre prefix (http://www.rpm.org/max-rpm/s1-rpm-reloc-building-relocatable.html). Le problème est comment faire fonctionner ces gestionnaires de paquet pour gérer autre chose que / ? Je ne suis pas sur que la réponse soit simple.

      Un de mes souci est aussi la coupure des dépendances. Avec un gestionnaire de paquet apt par exemple cela ne marcherais qu'au dessus d'une debian ou dérivée. Apt ne pourrait en effet pas trouver les dépendances dans la BDD d'une centos. Dans mon cas il faut que je fournisse un fichier de compatibilité de noms mais tout est possible. (ou bien il est possible d'utiliser la même approche avec un peu de patchs….).

      HomeLinux supporte aussi très facilement des paquets non reconnus en cherchant les sources sur le net, on peut donc l'utiliser pour ses propres projets qui ne sont pas gérés par les distributions. C'est un avantage non négligeable comparé à apt, rpm…..

      La description des paquets est très minimaliste pour facilité la maintenance et la mise à jour des numéros de version le plus automatique possible. On peut donc très facilement avoir accès aux toutes dernières versions. Je ne cherche pas ici à parler de stable/instable. On peut donc considéré HomeLinux comme un bac à sable pour tester facilement le mix des versions les plus à jour d'un ensemble de paquet. On offre donc un outils pour les développeurs.

      The force is in doing, not trying.

      • [^] # Re: intégration avec d'autres gestionnaires

        Posté par  . Évalué à 3.

        À creuser en effet. Je pense que la gestion du "/" peut se gérer simplement avec un chroot, voire un LXC en userspace. Au fond, l'idée que tu proposes est assez identique à un LXC/chroot => bac à sable où tu peux installer ce que tu veux (et là apt fonctionne bien, sans ajouter de code). Difficile de faire un bac à sable plus complet, tu peux installer toute une distribution dedans.

        La gestion du téléchargement et de l'installation automatique de trucs chopés sur github c'est sans doute utile pour quelques personnes, mais ce n'est qu'un tout petit plus par rapport à un apt. Pour l'idée d'avoir facilement un outil à disposition pour installer ses projets, là encore apt fait bien le travail, tu peux t'installer un dépôt et créer des paquets facilement.

        Peut-être que mon avis n'est pas pertinent, je passe peut-être à côté de quelque-chose, un besoin précis qui serait couvert par ton programme et seulement lui, mais je ne vois pas.

        • [^] # Re: intégration avec d'autres gestionnaires

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

          Chroot is limited to root users and maybe LXC too ? Or am I wrong ? My main use case is a user on a station without any root rights and without any kernel level virtual machine engine available. Otherwise yes you have plenty of available solutions, even using Gentoo in a chroot.

          The force is in doing, not trying.

        • [^] # Re: intégration avec d'autres gestionnaires

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

          Another point, as a developper who need some deps, I don't want to go throuth a 10 pages tutorial to setup my prefix. With HomeLinux I try to let the configuration as minimal as possible (maybe I fail… but I try ;) ).

          The force is in doing, not trying.

    • [^] # Re: intégration avec d'autres gestionnaires

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

      Je pense également à un point, à l'exception de portage (gentoo) et packman (arch), les gestionnaires de paquets sont plutôt conçus pour installer des paquets binaires déjà compilés.

      Ce qui pourrait être intéressant c'est d'ajouter la détection de dépendance dans gentoo prefix. Et la on retrouve quelque chose similaire à ce que fait HomeLinux avec une base de paquet existante mais toujours incomplète. Le problème dans ce cas c'est que si le paquet n'est pas géré vous êtes coincés, ce qui n'est pas le cas avec HomeLinux.

      The force is in doing, not trying.

  • # Nix ?

    Posté par  . Évalué à 10.

    Avais-tu évalué le gestionnaire de paquet Nix pour voir s'il convenait à tes besoins ? À vue de nez, Nix semble moins pensé pour l'intégration au système existant, mais il est peut-être plus poussé sur l'aspect reproductibilité (en particulier les hash d'environnements Nix peuvent être comparés entre machine pour vérifier que la configuration est bien identique).

    • [^] # Re: Nix ?

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

      Je ne connaissais pas, il faut que je regarde, merci pour le lien. Dans la même idée il y a EasyBuild (https://hpcugent.github.io/easybuild/) qui se base complètement sur module sauf erreur.

      Mon but est un peu différent, je cherche à considérer la construction d'un prefix cohérent avec des versions à jour (considérant le cas par exemple de mon ancien labo ou je devais travailler sur de vieilles centos sur lesquels je n'avais pas la main….). Je gère aussi module mais pour un nombre restrains de paquets pour lesquels cela à du sens (eg. multiples version de GCC).

      The force is in doing, not trying.

    • [^] # Re: Nix ?

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

      Il y a aussi https://www.gnu.org/software/guix/ qui semble etre l'alternative GNU a Nix.

  • # Lié à Gentoo ?

    Posté par  . Évalué à 2.

    je n'ai pas trop saisi, HomeLinux est concu pour tourner sur une Gentoo ou sur n'importe quel distro ?

    Emacs le fait depuis 30 ans.

    • [^] # Re: Lié à Gentoo ?

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

      Sur n'importe quelle distibution, il reprends juste certains concepts de Gentoo et utilise la base d'archive source Gentoo comme référence de secours pour les paquets non explicitement gérés.

      Sur le principe il doit aussi marcher sur MacOSX, mais avec du travail sur les paquets graphiques.

      The force is in doing, not trying.

Suivre le flux des commentaires

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