Le projet GNU s'enrichit d'un gestionnaire de paquets

Posté par  . Modéré par baud123. Licence CC By‑SA.
Étiquettes : aucune
38
28
août
2011
GNU

Le projet GNU, riche de dizaines de logiciels, s'est toujours contenté de fournir des archives téléchargeables des sources logiciels, laissant à l'utilisateur et aux distributeurs la tâche de les rendre utilisables (compilation, gestion des dépendances, etc.). Ce système fonctionne plutôt bien, puisque les outils GNU sont très répandus dans les parcs de systèmes UNIX installés, et sont même systématiquement fournis avec toutes les distributions à base de [Noyau Linux].

Cependant, cela avait un inconvénient : en cas de découverte d'anomalies, les utilisateurs avaient tendance à se retourner vers leur distributeur (qui ne remontait pas forcément l'information au projet GNU qui ne pouvait donc pas procéder à la correction), ou à l'inverse des anomalies spécifiques à certaines distributions étaient remontées au projet GNU par erreur. Le projet GNU src (source release collection) est destiné à pallier cet inconvénient.

Gsrc se présente sous la forme d'une simple archive à télécharger, contenant les outils qui génèrent un fichier Makefile à partir duquel il sera possible de compiler n'importe quel logiciel du projet Gnu. Par exemple, pour installer GPG, il suffira de lancer make -C gnu/gnupg, ce qui provoquera :

  • le téléchargement de la dernière version stable de GNU pg ;
  • le téléchargement de la dernière version stable de toutes les bibliothèques GNU nécessaires au bon fonctionnement de GNU pg (autrement dit, les dépendances) ;
  • la compilation de ce qui aura été téléchargé (en utilisant les mêmes options de configure que celles utilisées par la distribution).

Ensuite, on pourra compiler en une fois tout ce qui aura été téléchargé avec un classique make, puis installer l'ensemble avec le nom moins classique make install. Ainsi, toute personne découvrant un bug en utilisant logiciel GNU sera dorénavant invitée à installer la version fournie par gsrc avant de le remonter : si le bug est toujours constaté après installation via gsrc, il sera quasi-certain que celui-ci est lié au projet GNU.

Aller plus loin

  • # le non moins

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

    "le nom moins fameux" rappelle un peu Jacques Lacan

  • # Oui, mais non

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

    GNU SRC (Source Release Collection) provides a simple way to install the latest officially released versions of GNU packages on an existing distribution
    The aim is to make it easier to work with sources, and to help with development and bug reporting.

    Reprenons:

    a simple way to install the latest officially released versions of GNU packages

    Sauf que les numéros de version des packages sont dans les Makefile... ça ne prend pas automatiquement la dernière version disponible (et sinon y aurait probablement des trucs pétés à cause d'incompatibilités avec certaines versions de dépendances)

    Donc pour que ça soit effectivement les dernières versions, il faut maintenir les Makefiles...

    The aim is to make it easier to work with sources, and to help with development and bug reporting

    Et si y a un probleme avec la compilation du bousin, on s'adresse à qui ? au (visiblement) seul mec qui bosse sur le projet gsrc ?

    Et je suis vraiment pas convaincu que pour des problemes des différents projets (pas au niveau compilation, mais bugs à l'usage) passer par gsrc soit plus efficace pour remonter upstream que passer par un système de packaging d'une distribution X ou Y.

    Mais aussi: quid de la portabilité ?

    Je ne vois aucun avantage, mais des inconvénients, face à Pkgsrc, The NetBSD Packages Collection.
    Pkgsrc est portable, gère plus de 8000 packages et pas seulement les projets GNU, et est relativement à jour, puisqu'en rolling release trimestrielle.

    • [^] # Re: Oui, mais non

      Posté par  . Évalué à 4.

      Ça a l'air bien pkgsrc, et c'est présenté comme portable, mais est-ce que ça fonctionne aussi ailleurs que sur netbsd ? J'avais essayé de l'installer sur FreeBSD et ça m'avait semblé compliqué, et ensuite on m'a dit que c'était pas censé bien fonctionner dessus. J'avais essayé sur MacOSX, idem, c'était la croix et la bannière pour faire le moindre truc.

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Oui, mais non

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

        c'est présenté comme portable, mais est-ce que ça fonctionne aussi ailleurs que sur netbsd ?

        C'est portable en terme d'OS et en terme d'architecture. C'est le système officiel de gestion des packages de NetBSD, l'OS le plus portable, donc question arch ça se défend plutôt pas mal à priori.

        Coté OS c'est vraiment conçu pour être utilisable en dehors de NetBSD. Par exemple sur les autres BSD, Solaris (y a un projet pour l'utiliser plus ou moins officiellement avecpkgin sur Illumos), Minix, Mac Os X, les unix proprio... Il existe aussi une ou deux distro linux qui se basent dessus.
        Mais je ne peux te donner de retour personnel, n'ayant pas testé moi même en dehors de NetBSD. (des connaissances l'utilisent sur Solaris sans probleme)

        Pourquoi chez HP ils bloquent la numérisation et l'impression en noir et blanc lorsqu'il faut changer les cartouches couleurs ?

        Pas compris...

        • [^] # Re: Oui, mais non

          Posté par  . Évalué à 10.

          Pas compris...

          Il faut faire la différence entre le message et sa signature.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Oui, mais non

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

            Arf... La CSS que j'utilise ne donne pas d'indice !

            • [^] # Re: Oui, mais non

              Posté par  . Évalué à 0.

              C'est le «-- » qui précède qui est supposé indiquer que la suite est une signature, comme pour un courriel ;-)

              • [^] # Re: Oui, mais non

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

                Sans blague ?
                ben y a pas...

                • [^] # Re: Oui, mais non

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

                  Rajoute ceci dans ta css :

                  li.comment .content .signature:before {
    content: "-- \A ";
    white-space: pre-line;
}

                  et tu l'aura.

                  Et avec un peu de style aussi : 

                  li.comment .content .signature {
    color: #999999;
    font-size: 11px;
}

                  Et si ce n'est pas ta css, une solution "simple" :

                  • crée toi un fichier style.css (ou sketuveux.css)
                  • importe ta css préférée

                  @import url("http://linuxfr.org/stylesheets/contrib/grises.css");
                  • ajoute ensuite le code qui va bien
                  • héberge ça quelque part
                  • donne la gentille url à linousquèfère et ça roule !

                  Pour ma part, voici ma css (j'en avais déjà parlé dans un autre nourjal mais je sais plus où). Ca rajoute les signatures et la mise en évidence des nouveaux commentaires (je sais pas comment on navigue sans...)

                  @import url("http://linuxfr.org/stylesheets/contrib/grises.css?ad419bb");

.new_comments {
  color: #f57900;
}

li.comment .content .signature {
  color: #999999;
  font-size: 11px;
  }
  li.comment .content .signature:before {
    content: "-- \A ";
    white-space: pre-line;
    }

                  • [^] # Re: Oui, mais non

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

                    Excellent, merci :) !

                  • [^] # Re: Oui, mais non

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

                    Ça rajoute les signatures et la mise en évidence des nouveaux commentaires (je sais pas comment on navigue sans...)

                    Touches j et k, façon vi.

                    • [^] # Re: Oui, mais non

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

                      poua, jamais ! (je parle pour vi là...)

                      J'utilise depuis bien longtemps < et >, mais reste que je trouve que la mise en évidence visuelle, surtout sur la page des articles / journaux, manquait terriblement.
                      D'ailleurs ce qui est intéressant c'est l permettant d'accéder au prochain contenu avec plus de commentaires, alors que j/k </> amènent au prochain non lu.

                • [^] # Re: Oui, mais non

                  Posté par  . Évalué à 1.

                  Ah, oui, au temps pour moi : je me suis laissé avoir par ce que la feuille de style par défaut affiche ; dommage que toutes les feuilles de styles n'intègrent pas cette (bête) convention pour le rendu des signatures :-(

      • [^] # Re: Oui, mais non

        Posté par  . Évalué à 10.

        Ça a l'air bien pkgsrc, et c'est présenté comme portable, mais est-ce que ça fonctionne aussi ailleurs que sur netbsd ?

        Cela marche bien pour les paquets conçus "proprement", c'est à dire qui n'utilisent pas une API trop spécifique à un OS par exemple, ou qui n'ont pas de dépendances proprio.

        Généralement ces paquets sont tagués "For XXX only", ce qui lève un warning au make. Mais il arrive que certains passent entre les mailles du filet, on ne peut pas tout tester. Le buildbot en attrape beaucoup. Les ptit's gars de pkgsrc soumettent souvent des corrections upstream quand elles ne demandent pas trop d'effort.

        Suivant le degré de portabilité, cela ira du "marche sans problème" à "marche pas du tout." On peut pas faire tout juste du premier coup, n'en déplaise à ceux qui font du Minix (iMil et bapt, si vous me lisez :o ).

        Les plus galères sont pour moi les applications lourdes, particulièrement graphiques. Ayant dû porter pkgsrc pour compiler (cross-compiler aussi, si si) tout un tas d'applications, c'est clairement les gtk+, firefox, glib... qui pètent. Souvent sur des symboles non résolus, des erreurs de compilation, ou des fonctionnalités manquantes (par exemple, la dernière VM Javascript de Firefox s'en sort très mal ailleurs que sur x86). Dernièrement, j'ai découvert Vala, qui même s'il fait du source-to-source (C à la fin), le code généré est pas forcément... correct pour autre chose que du i386 (alignement).

        Perso, le plus pénible avec pkgsrc est le bootstrap, qui fait un peu "réservé aux initiés". Pas tant dans la complexité (c'est deux lignes de commandes à taper: un téléchargement, et ./bootstrap), mais dans le fait que quand on sait pas, il faut chercher un peu. Cela rebute pas mal.

        • [^] # Re: Oui, mais non

          Posté par  . Évalué à 3.

          la dernière VM Javascript de Firefox s'en sort très mal ailleurs que sur x86

          Il me semble que c'est à cause de ça qu'on ne retrouve pas une version supérieure à 3.5 dans Debian stable.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Oui, mais non

        Posté par  . Évalué à 3.

        Ça fait des bailles que FreeBSD utilise les 'ports' : toute une arborescence de makefile pour rapatrier / compiler / installer des binaires. Ça fait aussi longtemps que je m'en sers plus, mais il me semble aussi qu'il rapatrie les dernières versions des dépendances avant de compiler ...

        • [^] # Re: Oui, mais non

          Posté par  . Évalué à 1.

          oui, ça utilise les ports d'un côté, et netbsd utilise un autre format, pkgsrc. Dommage.

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Oui, mais non

        Posté par  . Évalué à 3.

        Je l'ai installé sur une Slackware et ça marche. Il y a juste un ou deux packages que je n'ai pas réussi à compiler, mais je n'ai pas eu le temps d'investiguer.

        Quand j'aurai un peu de temps je testerai sur [open]solaris, et si je le peux sur HP-UX. Si j'avais un AIX sous la main je le tenterais.

  • # Reference needed

    Posté par  . Évalué à -10.

    on parle même souvent de GNU/linux pour désigner le système d'exploitation

    Qui ? (Mis à part RMS)

    • [^] # Re: Reference needed

      Posté par  . Évalué à 9.

      Moi, ça permet de différencier l'OS que j'utilise et qui se retrouve dans plus ou moins toutes les distributions Linux des autres systèmes comme Android.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Reference needed

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

      Debian

    • [^] # Re: Reference needed

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

      Moi également. Les arguments de RMS me semblent justes.

      Nous pourrions également citer GNU/Linux Magazine France, etc. Pas Linus par contre ;-)

  • # rpm, deb ...

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

    Sur mes machines, j'utilise toujours des paquetages binaires (deb ou rpm selon la distribution employée). Pour garanti la cohérence de la base, les installations en tar.gz sont interdites. Je ne vois pas comment gsrc peut marcher dans ces conditions ?

    outil réservé aux gentoo, et autres bsd ?

    • [^] # Re: rpm, deb ...

      Posté par  . Évalué à 2.

      En fait la phrase de présentation officielle de l'outil (accessible depuis le premier lien) que j'aurais probablement dû traduire dans la dépêche est claire à ce sujet : "GNU SRC (Source Release Collection) provides a simple way to install the latest officially released versions of GNU packages on an existing distribution " (soit "GSRC fournit une méthode simple d'installation des paquets GNU dans une distribution existante"). L'objectif est bien d'avoir une gestion séparée des versions fournies par GSRC et celles fournies par la distribution, en installant par exemple les outils dans un sous-répertoire de son home directory. Cela se règle dans les options du configure de gsrc (l'exemple donné dans la doc est ./configure --prefix=$HOME/gnu).

      Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr

      • [^] # jhbuild

        Posté par  . Évalué à 2.

        L'objectif est bien d'avoir une gestion séparée des versions fournies par GSRC et celles fournies par la distribution, en installant par exemple les outils dans un sous-répertoire de son home directory.

        Ah oui, donc le principe est assez proche de jhbuild, qui est utilisé intensivement par les développeurs de GNOME pour installer la version en développement de certains modules, sans interférer avec ce qui est installé par la distribution.

  • # Le projet GNU s'enrichit d'un gestionnaire de paquets

    Posté par  . Évalué à 4.

    un gestionnaire de paquets donc.

    Ensuite, on pourra compiler en une fois tout ce qui aura été téléchargé avec un classique make, puis installer l'ensemble avec le nom moins classique make install

    make install ... il n'y a pas plus propre en effet pour installer un paquet :(

    • [^] # Re: Le projet GNU s'enrichit d'un gestionnaire de paquets

      Posté par  . Évalué à 2.

      Ca fait un peu peur mais les paquets compilés n'ont pas vocation à être installés directement dans le système, mais plutôt dans un répertoire tel que ~/gnu. Aucune chance de pourrir son système, donc, sauf à le faire exprès.

      • [^] # Re: Le projet GNU s'enrichit d'un gestionnaire de paquets

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

        Je vois 2 autres problèmes :

        • ça implique d'installer les paquetages "developpement".

        • Et rien n'assure que les options de compilation sont les mêmes que celles de sa distribution : les comportements ne seront pas comparables ...

        • [^] # Re: Le projet GNU s'enrichit d'un gestionnaire de paquets

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

          Concernant le premier problème, il me semble avoir lu que ce système permettait l’installation des dernières versions stables des outils.

          Pour le second problème, je crois avoir compris que c’est justement le but de ce système : identifier la source du problème, à savoir le logiciel GNU ou bien le travail effectué par la distribution lors de son intégration.

          • [^] # Re: Le projet GNU s'enrichit d'un gestionnaire de paquets

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

            Pour le second problème, je crois avoir compris que c’est justement le but de ce système : identifier la source du problème, à savoir le logiciel GNU ou bien le travail effectué par la distribution lors de son intégration.

            Pas totalement.
            Prends un logiciel complexe comme Linux, Firefox ou autres. Ces logiciels sont tellement gros qu'il y a des options à la compilation pour personnaliser un petit peu le résultat final (inclusion de trucs expérimentaux, d'un algorithme plus groumant en puissance mais économe en mémoire, etc.). Bien entendu, chaque distribution choisit les options.

            Mais si tu trouves un problème, sans le savoir, dans une de ces options activées et que le truc proposé par GNU par défaut ne l'active pas, tu vas conclure que le problème vient de la distribution. Alors qu'en fait, le bogue est bien dans le logiciel GNU, dans une des options qu'il propose.

            Ce dont sert cet outil, c'est de mettre en évidence si c'est l'intégration dans la distribution du dit logiciel qui a introduit ou non une couille.

    • [^] # Re: Le projet GNU s'enrichit d'un gestionnaire de paquets

      Posté par  . Évalué à 7.

      make install ... il n'y a pas plus propre en effet pour installer un paquet :(

      Effectivement.

      Dans une époque lointaine, quand je faisais ça à la main, GNU stow était mon grand ami.

      • [^] # Re: Le projet GNU s'enrichit d'un gestionnaire de paquets

        Posté par  . Évalué à 3.

        make install DESTDIR=/tmp/build_gnupg # qui installe dans le répertoire /tmp/build_gnupg

        et après, avec ton gestionnaire de paquets favori, tu construis le paquet pour ta distrib.

        Franchement, je ne vois pas l'intérêt de ce gsrc, ou alors j'ai pas compris. Promis, un jour je testerais ...

Suivre le flux des commentaires

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