Forum Linux.général Distribuer un binaire

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes : aucune
1
12
oct.
2020

Bonjour à tous,

J'ai reçu ce week-end une demande pour distribuer un paquet installable d'un binaire (compilé en OCaml). Or, il s'agit de quelque chose que je ne n'ai jamais fait, et je n'ai aucune idée de savoir par où commencer.

Dépendances

Le binaire n'utilise aucune librairie particulière, mais comment savoir quelles dépendances doivent être marquées (voilà par exemple la sortie de ldd) :

$ ldd i3_workspaces
        linux-vdso.so.1 (0x00007fff6e3fa000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fd797612000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd7975f0000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fd79757c000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd797438000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd797432000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd79726d000)
        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fd797067000)
        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fd796e61000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd797c12000)
        libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0 (0x00007fd796e47000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fd796e3c000)

Génération du packet

Est-ce qu'il y a des scripts ou des commandes qui permettent de créer un fichier deb de manière automatique ? Il faut que je regarde aussi du côté de dune (l'outil pour compiler le source), mais j'aimerai savoir s'il y a des outils génériques

Bonne hygiène git

Est-ce que vous conseillez de stocker les paquets dans le repo git ? Si non, comment-est ce que distribuez vos applications ?

Merci à vous pour vos retours !

  • # Début de réponse

    Posté par  . Évalué à 2.

    Salut,

    Je peux me tromper sur la première question, ne l'ayant jamais fait. L'approche que j'utiliserais, serait de prendre un paquet simple (puisque les dépendances sont limitées), faire un bon gros copier/coller et adapter (tests dans une VM avec une distribution de base, que tu snapshot avant d'installer ton paquet pour facilement revenir en arrière, par exemple ?).

    Pour le second point, j'aurai tendance à dire non. git, c'est bien pour le texte, mais les binaires, il me semble que c'est plus compliqué pour lui. Quand je faisais du packaging, ma méthode était d'avoir la toolchain qui générait le binaire, que je copiais (une fois les tests finis) sur un disque réseau (backupé) à côté de toutes les autres versions, et déployait la nouvelle version sur un ftp qui écrasait la version précédente afin que les clients n'aient qu'un choix : la dernière version. Mais si bug, comme j'avais les précédentes en interne, le roll-back était rapide.

    Je ne sais pas si ce workflow peut t'aider, et tu es libre de l'adapter ;)

    Matricule 23415

    • [^] # Re: Début de réponse

      Posté par  . Évalué à 2. Dernière modification le 12 octobre 2020 à 10:01.

      Re-salut,

      Petit complément.

      À l'époque, j'utilisais svn, pas git. Donc les infos sont peut-être fausses pour le binaire.

      Cependant, ce que j'ai petit à petit commencé à faire avec git, c'est poser un tag quand c'est prêt.

      Oui, ça fait un peu "ceinture et bretelles". Il y a d'un côté une sauvegarde du binaire généré, et de l'autre la possibilité de revenir à l'état de dev à ce moment.

      Bonne chance ;)

      Matricule 23415

  • # Laisser ça aux mainteneurs de distributions

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

    Sous Linux on a plutôt tendance à ne fournir les applications sous forme de code source. Principalement parce qu'il y a beaucoup trop de distributions et que compiler ton projet sous Ubuntu ne signifie pas qu'il fonctionnera sous une autre (libc différente, versions de bibliothèque différente, etc…).

    Faire un paquet 100% portable non compilé par les mainteneurs de la distribution signifierait que tu doives embarquer toutes les bibliothèques à côté de l'exécutable et jouer avec LD_LIBRARY_PATH pour ne jamais utiliser les bibliothèques du système et franchement c'est merdique. L'autre solution serait de faire des exécutable statique mais c'est peu recommandable.

    Enfin, la dernière solution et la plus appropriée si on veut fournir un paquet 100% portable binaire est de passer via flatpak mais ça rejoint un peu l'idée du paragraphe au dessus (les bibliothèques sont empaquetées avec). Cela dit, flatpak est plutôt orienté application graphiques (comprendre, avoir un .desktop qui s'affiche dans les menus GNOME/KDE/Xfce), ce qui n'a pas l'air d'être le cas de ton projet.

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Laisser ça aux mainteneurs de distributions

      Posté par  . Évalué à 2. Dernière modification le 12 octobre 2020 à 10:40.

      Salut,

      Faire un paquet 100% portable non compilé par les mainteneurs de la distribution signifierait que tu doives embarquer toutes les bibliothèques à côté de l'exécutable

      C'est effectivement un point important que j'ai oublié de mentionner, merci de l'avoir souligné.

      Dans mon expérience de "packager", c'était pour du windows, et ça ne se passait pas pareillement, vu les options.

      Donc, mon installeur devait embarquer toute la jvm et décider à l'installation :

      • jvm déjà là et en bonne version ? ok, on zappe cette étape,
      • sinon, on installe dans son petit coin pour pas déranger le reste.

      Bien évidemment, entre 32 et 64 bits, bah c'est pas la même jvm… donc fallait les deux pour un exe autonaume :p

      Mon installeur a vite pris du poids ;)

      Matricule 23415

      • [^] # Re: Laisser ça aux mainteneurs de distributions

        Posté par  . Évalué à 2.

        Salut,

        Auto-réponse :(

        donc fallait les deux pour un exe autonaume

        Comme c'est un peu vieux, je crois qu'il m'en fallait 4 en fait, à côté de tout le code binaire :

        • deux (32/64) si l'utilisateur souhaitait une installation globale au système,
        • et deux autres pour une installation locale juste pour le logiciel.

        Comment bien faire mieux grossir un installeur autonome ? :p

        Matricule 23415

    • [^] # Re: Laisser ça aux mainteneurs de distributions

      Posté par  . Évalué à 2.

      L'autre solution serait de faire des exécutable statique mais c'est peu recommandable.

      Pourquoi?
      Si c'est pour l'ASLR, il me semble bien que c'est possible aussi avec des binaires statiques. De plus, il y a plus d'optimisations possibles grâce au LTO. Si le problème est la mise à jour des dépendances, alors aucune solution ne sera jamais parfaite, même si dans l'idéal reposer sur les versions de l'hôte me semble le moins idiot.

      Là ou ça va être chiant, c'est la compilation. C'est pénible à faire le link statique, avec des erreurs bien chiantes et très peu d'aide du linker pour les gérer.

      Cela dis, pour linux, les libs qu'il utilise semble vraiment classiques. Il serait surprenant qu'une distro ne les ait pas déjà empaquetées.

    • [^] # Re: Laisser ça aux mainteneurs de distributions

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

      Laisser ça aux mainteneurs de distributions

      Trouve-moi un mainteneur de chaque distro qui fera le taf pour toutes mes logiciels, et je considérerai cette réponse comme acceptable. En attendant c'est juste du mensonge, car c'est pas du tout faisable sauf exception (que la licence soit libre, que tu trouves un mainteneur qui veuille bien faire le taf, que tu puisses attendre 6 mois ou 6 ans avant que ça se fasse en vrai), et surtout ça gèle la version du logiciel pour x années (durée de vie de la version de la distro), bref trop d'inconvénients même en trouvant quelqu'un.

      A noter qu'Apple a pris tout ce qui était bien dans la notion de repo Linux et a flingué les mauvais côtés, pas pour rien que chez eux ça marche bien plus (en plus d'être bankable).

      L'autre solution serait de faire des exécutable statique mais c'est peu recommandable.

      Mais quand c'est ce qu'il y a de "moins pire", on fait avec, la faute à ceux qui mettent des bâtons dans les roues pour autre chose.

      Bref, arrêtez cette phrase "Laisser ça aux mainteneurs de distributions", elle est ridicule et dégoûtent les gens qui la gobent puis découvrent la réalité, c'est en pratique une très mauvaise publicité sur la "communauté Linux".

      • [^] # Re: Laisser ça aux mainteneurs de distributions

        Posté par  . Évalué à 0. Dernière modification le 13 octobre 2020 à 13:17.

        Même s’il y avait des mainteneurs pour tous les logiciels et toutes les distros, ce serait contre-productif.

        Pourquoi faudrait-il que chaque logiciel soit adapté pour chaque distribution ?
        Pourquoi faudrait-il que les utilisateurs se contentent de la version packagée par la distribution ?
        Pourquoi pas des versions vanilla plutôt que des versions modifiées on ne sait comment, on ne sait pour quelle raison ?
        Pourquoi faudrait-il des mainteneurs ?
        Quand les logiciels seront-ils enfin séparés de la distribution ? La dernière fois que j’ai utilisé Linux, c’était pour compiler LibreOffice. Et pour ça, il fallait GCC 7 qui m’a demandé, pour s’installer, de désinstaller grosso modo tout le bureau et toutes ses dépendances, probablement la moitié du système… Formidable… Bref, j’ai fait viré la distro.

  • # C'est cadeau

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

    Salut, j'ai pris un peu de temps et j'ai regardé comment créer un binaire static en Ocaml.

    La seule chose que j'ai modifié est ton fichier src/dune où j'ai rajouté la ligne
    (flags (-ccopt -static))

    (libraries
    configuration
    common
    handlers
    lwt
    )
    (flags (-ccopt -static))
    (preprocess (pps lwt_ppx ppx_deriving_argparse))

    Les commandes sont les suivantes:

    docker run --name i3_workspaces -ti ocaml/opam2:alpine sh
    sudo apk add m4 pcre-dev
    git clone https://github.com/Chimrod/i3_workspaces.git
    cd i3_workspaces
    opam install . --deps-only --yes
    dune build

    Ensuite, dans ~/i3_workspaces/_build/default/src, se trouvent les deux exe i3_workspaces.exe et i3dot.exe, pour les avoir en local sur le pc, il suffit de faire :
    docker cp i3_workspaces:/home/opam/i3_workspaces/_build/default/src/i3_workspaces.exe .
    docker cp i3_workspaces:/home/opam/i3_workspaces/_build/default/src/i3dot.exe .

    Puis les deux fichiers peuvent être packagés avec FPM : https://fpm.readthedocs.io/en/latest/index.html

    mkdir -p i3_workspaces/opt/i3_workspaces
    mv i3_workspaces.exe i3_workspaces/opt/i3_workspaces
    mv i3dot.exe i3_workspaces/opt/i3_workspaces
    fpm -s dir -t deb -n i3-workspaces -v 0.2 -C ./i3_workspaces

    Du coup, tu obtiens un fichier i3-workspaces_0.2_amd64.deb que tu peux installer n'importe où sur une base DebiaN. À noter qu'il est aussi possible de distribuer une archive, un RPM, etc.

    Enfin pour les fichiers générés, je te conseillerais de créer une release sur Github, cela te permet que les gens accèdent aux bons fichiers en bonne version et tu n'as pas à gérer l'hosting.

    Exemple: https://github.com/ocaml/ocaml/releases/tag/4.11.1
    Doc: https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/managing-releases-in-a-repository

    Enfin, si tu veux, on peut automatiser les étapes ci-dessus avec Github actions, CircleCI, TravisCI, etc.

    • [^] # Re: C'est cadeau

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

      Wow ! Super, je n'en attendais pas tant…

      Merci beaucoup pour la réponse détaillée, je vais déjà essayer de le reproduire bêtement dans un premier temps, et voir comment m'en sortir !

      • [^] # Re: C'est cadeau

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

        Aucun soucis, n’hésite pas si tu as un soucis et si besoin, c’est facile d’automatiser.

        • [^] # Re: C'est cadeau

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

          Merci beaucoup, tu ne m'as pas seulement montré le chemin, mais également posé les rails !

          À priori j'arrive à m'en sortir :) je me suis permis d'ajouter "fpm" dans l'image docker, il faut juste maintenant que je prenne le temps d'automatiser tout ça.

          • [^] # Re: C'est cadeau

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

            Oui, après tout dépends de ta stratégie de release, mais l'idéal serait d'avoir un Dockerfile avec les bonnes commandes. Ensuite, tu build et dans ton outil de CI/CD, tu crée des artéfacts que tu peux ensuite publier sur GitHub.

  • # Faire un .deb binaire, c'est trivial

    Posté par  . Évalué à 5.

    À condition de ne pas viser son intégration dans Debian, j'entends, parce que sinon il faut faire un .deb source, et ça, c'est une autre paire de manches.

    Ce que je faisais au taf, en gros, c'était dans ce goût là:

    Créer un fichier monprojet/DEBIAN/control, les champs que l'on utilisait étaient: Package, Version, Description, Architecture, Depends et c'est tout.

    Bon, en vrai, j'avais bricolé un script de 100-150 lignes qui générait la structure du paquet, à savoir quelque chose qui ressemblait à ça:

    ./DEBIAN/control
./DEBIAN/md5sums (ou shasums? Je sais plus, suis pas chez moi, je re-répondrai ce soir au pire?)
./DEBIAN/conf (qui n'étais au final pas nécessaire)
./usr/bin/monbinaire (ou l'équivalent pour les libs bien sûr)
./etc/maconfig

    Puis le script lançais la commande pour générer le binaire: dpkg -b mondossier. À noter qu'il gérait aussi d'autres bricoles comme les fichiers de dictionnaires et autres, et que, je pense que niveau légal c'était pourri, vu que pas de fichiers de licences. Ça avait été fait (comme toujours) dans l'urgence, mea culpa (et j'en avais marre du tar -xf foo qui me donnais des sueurs froides quand j'avais pas inspecté les tarballs des collègues!).

    La config était stockée par moi et au moins un collègue dans un repo séparé (un autre ne le faisait pas, ça lui a rajouté quelques heures de boulot pour réparer ses oubli, surtout avec les connexions radio qui sont pas toujours géniales… mais c'était plus mon problème a ce stade), de sorte qu'au final on avait un paquet pour le binaire/la lib, et un autre pour la config. Elle contenait aussi souvent les scripts d'init (runit en fait).

    Ceci dit, encore une fois, le but n'étais pas d'intégrer dans Debian (close source t'façon, et code de merde en plus).
    Je pense que cette façon de faire est parfaitement acceptable (modulo l'aspect licence) pour un projet libre qui veut juste filer un binaire qui marche à ses utilisateurs, n'en déplaise aux perfectionnistes (et n'en déplaise aux râleurs: le format des paquets binaires de Debian est simple, robuste et très puissant).

    Le gros problème est que la doc pour ces infos n'est pas super simple à trouver, j'avais en fait reverse un binaire (avec dpkg-deb -R) avant de trouver une référence.

    En espérant que ça aide.

  • # Flatpak et autre ?

    Posté par  (Mastodon) . Évalué à 3.

    Je ne suis pas du tout spécialiste, mais une piste serait de regarder du côté des distributeurs binaires comme Flatpak, AppImage ou Snap. C'est exactement leur but non ?

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Suivre le flux des commentaires

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