• [^] # Re: courage

    Posté par . En réponse au journal 0 Linux epsilon. Évalué à 3.

    Oui, c'est sûr que pour ceux qui considèrent la gestion des dépendances comme une fonctionnalité importante, Spack n'aura que peu d'intérêt. Pour les autres (les Slackeux et ceux qui comme apostle font tourner leur propre distro) :

    • codé en shell POSIX au max. Je développe avec mksh, et m'efforce de systématiquement tester la bête avec dash (sh étant bash sur ma Slack, de fait je le teste quotidiennement avec ce shell). Pour les commandes utilisées, j'ai essayé de coller à la norme le plus possible (en hors norme, il doit y avoir stat et l'option -maxdepth de find). Le but est de fournir un truc solide et portable au moins sur une Busybox ;
    • 100% de compatibilité Slackware. Les Slackeux peuvent l'installer et le tester sur leur Slack sans soucis (c'est ce que je fais depuis plus d'un an). On peut désinstaller un paquet spack avec les pkgtools (aucune différence avec un paquet orthodoxe une fois installé), et convertir facilement un paquet Slack t[xg]z en paquet Spack. Je le souligne, parce que justement le gestionnaire est né de réflexions suite à l'étude du code des pkgtools. J'avais alors plein d'idées d'optimisation et de refontes, mais jusqu'à 0linux aucune motivation à les coder à l'idée que personne ne l'utiliserait sérieusement ;
    • un toolkit complet et cohérent : tout est pris en charge par une commande dédiée, préparation du paquet (spackcook), génération (spackpkg), rangement des archives (spacktidy), (dés)installation (spackadd/rm), exploration des paquets installés (spacklist), et même recherche des fichiers sur l'ensemble des paquets de la distro (spackfind, qui peut donc faire office de gestionnaire de dépendances du pauvre). Le plus gros des scripts fait 573 lignes, commentaires, écran d'aide et licences compris ;
    • un mode d'install qui permet de cantonner Spack à la gestion de /usr/local. Pour ceux qui ont l'habitude de blinder cette arbo à la grouik, Spack peut être une bonne solution pour gérer ça proprement en restant indépendant de la distro ;
    • un projet ouvert au fork. C'est un peu périphérique, mais ça ne me choque absolument pas qu'on forke Spack (une distro doit avoir la main sur son gestionnaire ! ), c'est même un peu pensé pour ça en offrant une base en shell (très souple et facilement adaptable) la plus saine et la plus compacte possible.

    Voilà, c'est à peu près tout, je pense. Je n'imagine pas un avenir particulièrement brillant pour le projet, mais je dois avouer que je suis pour le moment assez content du résultat, d'où quand même un gros merci à 0linux. :)