Journal Construire des paquets DEB pour Debian (deuxième partie)

Posté par (page perso) . Licence CC by-sa.
Tags :
14
23
avr.
2018

Sommaire

Le fichier watch et la commande uscan, ou comment faire la plus grosse partie du travail d'un mainteneur

Dans le dernier billet, nous avons vu ensemble pour importer des sources d'un paquet sur Ubuntu pour le construire sur et pour une Debian stable, je vous propose donc de continuer sur la possibilité d'automatiser une grosse partie du processus si une nouvelle version amont sort.

Nous retournons dans nos sources du paquet Ghostwriter que nous venions de faire, et allons voir le fameux fichier watch vu ensemble et dont je disais:

Le dernier fichier que j’explique ici est assez simple, c’est celui qui va permettre de contrôler si une nouvelle version est disponible, si bien rempli, il va même télécharger via la commande uscan la dernière version, on verra ensemble son utilisation pour la mise en paquet de la nouvelle version de Ghostwriter. (plus d’info: https://www.debian.org/doc/manuals/maint-guide/dother.fr.html#watch)

Il ressemble donc à ceci actuellement:

    ~/Paquets/ghostwriter/ghostwriter-1.6.0/debian$ cat watch 
    version=3
    https://github.com/wereturtle/ghostwriter/releases /wereturtle/ghostwriter/archive/v(.+)\.tar\.gz

Normalement mais c'est rarement le cas (je n'en ai vu que très peu le faire), la ligne de l'adresse devrait finir par debian uupdate , ce qui permet de faire tout automatiquement en faisant la commande uscan: les sources de la nouvelle version seront automatiquement recherchées, téléchargées, et la commande uupdate sera exécutée. Si la commande uscan télécharge les nouvelles sources mais n'exécute pas la commande uupdate, vous devriez corriger le fichier debian/watch pour avoir debian uupdate après l'URL. N'étant pas le cas pour Ghostwriter, nous corrigeons comme ceci:

    ~/Paquets/ghostwriter/ghostwriter-1.6.0/debian$ cat watch 
    version=3
    https://github.com/wereturtle/ghostwriter/releases /wereturtle/ghostwriter/archive/v(.+)\.tar\.gz debian uupdate

Et nous lançons uscan pour que les outils fassent le boulot à notre place:

    ~/Paquets/ghostwriter/ghostwriter-1.6.0$ uscan
    uscan: Newest version of ghostwriter on remote site is 1.6.2, local version is 1.6.0
    uscan:    => Newer package available from
      https://github.com/wereturtle/ghostwriter/archive/v1.6.2.tar.gz

Normalement tout a été fait si le fichier watch est bien fait:

    ~/Paquets/ghostwriter$ ls
    ghostwriter-1.6.0                           ghostwriter_1.6.0-1~schav1_amd64.deb      ghostwriter-1.6.2                            v1.6.2.tar.gz
    ghostwriter_1.6.0-1~schav1_amd64.build      ghostwriter_1.6.0-1~schav1.debian.tar.xz  ghostwriter-1.6.2.orig
    ghostwriter_1.6.0-1~schav1_amd64.buildinfo  ghostwriter_1.6.0-1~schav1.dsc            ghostwriter_1.6.2.orig.tar.gz
    ghostwriter_1.6.0-1~schav1_amd64.changes    ghostwriter_1.6.0.orig.tar.gz             ghostwriter-dbgsym_1.6.0-1~schav1_amd64.deb

Il y a bien le nouveau ghostwriter_1.6.2.orig.tar.gz (nomination Debian des sources non debianisés) qui est un lien symbolique vers v1.6.2.tar.gz, le dossier ghostwriter-1.6.2.orig (sans modifications donc!) et le dossier ghostwriter-1.6.2 avec la debianisation, c'est-à-dire le sous-dossier debian. On s’arrête pour parler de ce qui vient de se passer, je sais pas si vous vous rendez compte du taf qui a été fait automatiquement et sans que vous n'ayez à bouger vos petits doigts? Je vais donc le dire, les outils ont détecté une nouvelle version en amont sur le site de l'auteur, la 1.6.2, ils ont donc téléchargé l'archive de cette version nommé en amont v1.6.2.tar.gz, ils ont fait un lien symbolique de cette archive en le nommant à la manière Debian, c'est-à-dire ghostwriter_1.6.2.orig.tar.gz (nommage que Debian emplois pour les sources non encore debianisées donc n'ayant pas subi de changement/ajout du dossier debian). De là, ils ont décompressé l'archive symbolique dont le dossier résultant a pour nom ghostwriter-1.6.2.orig, ils l'ont copié en supprimant le .orig du nom et ils lui ont déposé notre dossier debian de notre build précédent. Mais c'est pas tout, les outils ont nettoyé ce dossier (debian) des fichiers résultants de la compilation et ont complété le changelog:

    ~/Paquets/ghostwriter/ghostwriter-1.6.2/debian$ cat changelog 
    ghostwriter (1.6.2-1) UNRELEASED; urgency=medium

    * New upstream release

    -- Sebastien CHAVAUX <seb95.scou@gmail.com>  Fri, 20 Apr 2018 23:21:31 +0200

    ghostwriter (1.6.0-1~schav1) unstable; urgency=low

    * package for Debian

    [ wereturtle ]
    * New upstream release.

    -- Sebastien CHAVAUX <seb95.scou@gmail.com>  Fri, 20 Apr 2018 19:21:47 +0200

    ghostwriter (1.5.0+ds2-1ppa2~trusty1) trusty; urgency=low

    * Dependency fix for Artful Aardvark.

    -- wereturtle <wereturtledev@gmail.com>  Thu, 31 Aug 2017 23:00:00 -0700

Maintenant que cet aparté est fini, il ne reste plus qu'a lancer la compilation avec debuild:

    ~/Paquets/ghostwriter/ghostwriter-1.6.2/debian$ debuild
    [....]
    Now running lintian...
    W: ghostwriter source: maintainer-also-in-uploaders
    W: ghostwriter: command-in-menu-file-and-desktop-file ghostwriter usr/share/menu/ghostwriter:7
    Finished running lintian.
    Now signing changes and any dsc files...
    signfile dsc ghostwriter_1.6.2-1.dsc xxxxxxxxxxxxxxxxxxxxxx

    fixup_buildinfo ghostwriter_1.6.2-1.dsc ghostwriter_1.6.2-1_amd64.buildinfo
    signfile buildinfo ghostwriter_1.6.2-1_amd64.buildinfo xxxxxxxxxxxxxxxxxxxxxxx

    fixup_changes dsc ghostwriter_1.6.2-1.dsc ghostwriter_1.6.2-1_amd64.changes
    fixup_changes buildinfo ghostwriter_1.6.2-1_amd64.buildinfo ghostwriter_1.6.2-1_amd64.changes
    signfile changes ghostwriter_1.6.2-1_amd64.changes xxxxxxxxxxxxxxxxxxxxxx

    Successfully signed dsc, buildinfo, changes files

J'aurais pu comme pour la version 1.6.0, rajouter le préfixe ~schav1 à l'aide de dch -r:

    ~/Paquets/ghostwriter/ghostwriter-1.6.2/debian$ dch -r
    ghostwriter (1.6.2-1~schav1) unstable; urgency=medium

    * New upstream release

    -- Sebastien CHAVAUX <seb95.scou@gmail.com>  Sat, 21 Apr 2018 00:36:52 +0200

    ghostwriter (1.6.0-1~schav1) unstable; urgency=low

    * package for Debian

    [ wereturtle ]
    * New upstream release.

    -- Sebastien CHAVAUX <seb95.scou@gmail.com>  Fri, 20 Apr 2018 19:21:47 +0200

Nous auront donc nos paquets et nos fichiers d’après build:

    ~/Paquets/ghostwriter$ ls 
    ghostwriter-1.6.0                           ghostwriter_1.6.2-1_amd64.build             ghostwriter_1.6.2-1~schav1_amd64.deb
    ghostwriter_1.6.0-1~schav1_amd64.build      ghostwriter_1.6.2-1_amd64.buildinfo         ghostwriter_1.6.2-1~schav1.debian.tar.xz
    ghostwriter_1.6.0-1~schav1_amd64.buildinfo  ghostwriter_1.6.2-1_amd64.changes           ghostwriter_1.6.2-1~schav1.dsc
    ghostwriter_1.6.0-1~schav1_amd64.changes    ghostwriter_1.6.2-1_amd64.deb               ghostwriter-1.6.2.orig
    ghostwriter_1.6.0-1~schav1_amd64.deb        ghostwriter_1.6.2-1.debian.tar.xz           ghostwriter_1.6.2.orig.tar.gz
    ghostwriter_1.6.0-1~schav1.debian.tar.xz    ghostwriter_1.6.2-1.dsc                     ghostwriter-dbgsym_1.6.0-1~schav1_amd64.deb
    ghostwriter_1.6.0-1~schav1.dsc              ghostwriter_1.6.2-1~schav1_amd64.build      ghostwriter-dbgsym_1.6.2-1_amd64.deb
    ghostwriter_1.6.0.orig.tar.gz               ghostwriter_1.6.2-1~schav1_amd64.buildinfo  ghostwriter-dbgsym_1.6.2-1~schav1_amd64.deb
    ghostwriter-1.6.2                           ghostwriter_1.6.2-1~schav1_amd64.changes    v1.6.2.tar.gz

On peut voir les fichiers en rapport avec la version 1.6.0 débianisé par votre serviteur, ceux de Ubuntu (les originaux) ne sont plus là ayant été mit à la corbeille, ceux de la version 1.6.2 avec et sans le préfixe de mes paquets personnels (~schav1).

  • # Markdown linuxfr différent de celui de mon système?

    Posté par (page perso) . Évalué à 3. Dernière modification le 23/04/18 à 19:13.

    Ça merde pas mal le markdown et comme a mon habitude je valide ne voyant rien de mal au début… Sauf qu'il y a beaucoup de différences, des placement qui diffère, du code qui n'est pas en code, …

    désolé pour le raté…

    Bon du coup le billet est par là:
    https://passiongnulinux.tuxfamily.org/post/construire-des-paquets-deb-pour-debian-suite/

  • # PKGBUILD

    Posté par . Évalué à -1.

    On fait aussi plusieurs billets pour les PKGBUILD d'archlinux ou on considère que la page de wiki suffit largement ?

    Je comprends maintenant pourquoi j'ai toujours détesté manipuler des .deb.

    • [^] # Re: PKGBUILD

      Posté par . Évalué à 1.

      Même Zenitram n'est pas venu troller c'était vraiment obligé de venir faire ton commentaire ?

      Tu utilise une distribution différentes qui a des objectifs différents et donc qui fonctionne différemment. Est-ce qu'il est pour autant nécessaire d'être condescendant ? Est-ce qu'il faut que tout le monde se plie aux usages de ta distribution ?

    • [^] # Re: PKGBUILD

      Posté par . Évalué à 3.

      Arch publie des bouts de code downloadés et empaquetés sans modifs. Debian maintiens une distro sur plusieurs années en corrigeant les problèmes de sécurités de bases de code parfois obsolète.

      Donc, la différence, c'est que Debian nécessite un travail de développement sur les paquets, qui n'est pas pertinent dans une rolling release.

      Je comprends maintenant pourquoi j'ai toujours détesté manipuler des .deb.

      Heureusement que je n'ai pas attendu ton commentaire pour comprendre pourquoi les utilisateurs les plus bruyants (je suis sûr que ce n'est pas la majorité, ceci dit. Enfin, j'espère.) d'arch me les cassent…

      • [^] # Re: PKGBUILD

        Posté par . Évalué à 4.

        Donc, la différence, c'est que Debian nécessite un travail de développement sur les paquets

        Je ne vois pas le rapport entre le patchage des sources et le mode de construction des paquets. Arch patche certains paquets. Exemple:
        https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=freecad

      • [^] # Re: PKGBUILD

        Posté par (page perso) . Évalué à 3.

        C'est complètement stupide ce que tu dis, sans l'upstream Debian est la plupart du temps incapable de maintenir sur le long terme un paquet. Si l'upstream ne fait plus de mise à jour se sécurité, ben tu as un gros tas de merde dans Debian…

        Autant ça fonctionne plutôt bien sur les logiciels à évolution lente (apache, mysql, …) donc sur les serveurs mais sur la partie bureautique, ils sont à la ramasse…

        Et cela n'a donc rien à voir avec makepkg, tu pourrais très bien faire une ArchLinux avec un support de 5 ans si tu avais déjà gens motivés pour faire la maintenance. Sachant que tu retrouverais le même problème que pour Debian, à savoir une grosse bouse niveau sécurité sur certains softs.

        Mais il est clair que les paquets debian sont compliqués à faire, bien plus qu'un RPM, bien plus qu'un paquet ArchLinux et je te raconte pas pour eopkg…

        • [^] # Re: PKGBUILD

          Posté par (page perso) . Évalué à 2.

          Et pourtant ce n'est pas stupide, et oui debian maintient comme d'autres distributions des logiciels sur le long terme et redescend des correctifs ou font eux même des correctifs. Ce que arch ne fait pas du à son système de sortie(rolling). Par contre dire que sous debian on est dans la merde si l'upstream c'est du n'importe quoi, que dire alors de centos, redhat, suse?

          La partie du bureau à la ramasse sous debian , oui je l'entends tous les jours et ça n'empêche pas les debianeux de l'utiliser aussi la stable pour leur desktops.

          J'aimerais bien connaître ou debian est une grosse bouse au niveau de la sécurité ? Par contre arch faire de la maintenance sur 5 ans j'aimerais bien voir ça, il n'y a personne et surtout personne veux se faire chier et préfère juste confier la sécurité sur des paquets mis à jour continuellement.

          Pour la difficulté de faire un paquet debian, tout dépend des outils utilisés, si on utilise les outils les plus évolué c'est 80% du travail fait automatiquement, je viens plus haut dans ce journal démontrer que le taf a été fait à 100% je n'avais rien à faire pour faire mon nouveau paquet à par lancer deux commandes.

          Maintenant à partir de zéro le paquet debian fait peur car il n'y a pas un fichier à remplir mais plusieurs, c'est juste impressionnant mais une grosse partie est faite en automatique, mais c'est comme tout faut en faire quelques un pour être à l'aise. Par exemple je ne suis pas bien à l'aise avec les RPM, il y a toujours un trucs qui merde si on reprends un spec d'une autre distribution, et je m'en sors donc mieux avec le deb.

          • [^] # Re: PKGBUILD

            Posté par (page perso) . Évalué à 4.

            La partie du bureau à la ramasse sous debian

            Tu veux un exemple, ça m'a pris 5 minutes pour trouver:
            https://packages.debian.org/fr/stretch-backports/libwebkit2gtk-4.0-37

            Version 2.18 avec juste des patchs pour compiler sur les différentes archis et pourtant:
            https://webkitgtk.org/security/WSA-2018-0003.html

            Donc du coup, il est possible d'envoyer un mail (geary, evolution, …) ou de faire un site (midori, epiphany, …) pour piéger un utilisateur de Debian stable.

            Pas de patch upstream car les devs ne supportent pas les version n-1 et comme ça va contre la politique de Debian, ben il ne se passe rien.

            https://bodhi.fedoraproject.org/updates/?builds=webkitgtk4-2.20.1-1.fc26

            Fedora est à jour elle par exemple.

            c'est juste impressionnant

            Non, c'est juste le bordel, le fichier rules, y'a 300 façon différentes de le remplir, rien que ça, je trouve ça non intuitif. Tu es souvent obligé d'aller voir dans d'autres paquet et comme personne ne fait pareil… (même chez debian). Je fais des paquets pour Debian, Fedora, Suse, Arch, Solus et c'est vraiment le bordel sous Debian, crois moi.

            Et pourtant, je suis un fan de Debian, c'est pas du troll…

            • [^] # Re: PKGBUILD

              Posté par (page perso) . Évalué à 2.

              Pour la lib de webkitgtk, normalement c'est assez suivi entre les version intermédiaires, de toute façon debian le précise que seul mozilla a du support et que pour les autres c'est démerdez vous…

              Bah j'ai fait des paquets suse et debian mais aussi des arch, frug, 0linux(morte), nutyx ,… je trouve pas que les debian sont particulièrement difficile, c'est vachement automatisé avec dh_make. Tu utilises quoi?
              Du reste, et la je ne parle que d'exportation de paquets, c'est plus simple de prendre un paquet source de deb comme ubuntu pour faire un paquet debian et vise-versa que des RPM, fedora pour opensuse et (vise versa) dont je suis toujours à la recherche de ce qui va merder.

              Maintenant oui, il y a milles et une façons de faire des deb, du plus emmerdant et moins automatisé au plus automatisé.

              • [^] # Re: PKGBUILD

                Posté par (page perso) . Évalué à 2.

                Donc tu avoues que la plupart des applications graphiques sous Debian stable sont trouées jusqu'à la moelle, CQFD…

                • [^] # Re: PKGBUILD

                  Posté par (page perso) . Évalué à 1.

                  Pour ce qui est des navigateur oui, pour le reste non, libreoffice est patché, le kernel aussi, firefox c'est esr,…

                  • [^] # Re: PKGBUILD

                    Posté par (page perso) . Évalué à 2.

                    Je pense que tu sous estimes le nombre d'applications dépendant de webkitgtk…

            • [^] # Re: PKGBUILD

              Posté par . Évalué à 2.

              Tu veux un exemple, ça m'a pris 5 minutes pour trouver:
              https://packages.debian.org/fr/stretch-backports/libwebkit2gtk-4.0-37

              Je ne suis pas allé voir, mais là, tu parles dans les backports… C’est à dire des versions plus récentes que celle maintenu par l’équipe de sécurité qui est dans stable.

              Merci de me corriger si je dis une connerie.

        • [^] # Re: PKGBUILD

          Posté par . Évalué à 2.

          donc sur les serveurs mais sur la partie bureautique, ils sont à la ramasse…

          C'est à dire? Tu as entendu parler d'une faille de sécurité non corrigée pendant longtemps alors que toutes les autres distros qui font du support sur le temps avaient corrigé le problème?

          Et cela n'a donc rien à voir avec makepkg, tu pourrais très bien faire une ArchLinux avec un support de 5 ans si tu avais déjà gens motivés pour faire la maintenance.

          Bien sûr, ce problème n'a rien à voir avec le système de paquet: il est lié au fait de ne pas être une rolling release. Une rolling release peut se contenter de suivre le code originelle. Les autres sont obligées de patcher, surtout si l'upstream n'en a rien à foutre des versions de plus de 6 mois (de mémoire, il me semble que c'est une source de problèmes pour kde, mais je dis sûrement de la merde vu que je ne m'intéresse pas aux bureaux lourds).

          Mais il est clair que les paquets debian sont compliqués à faire, bien plus qu'un RPM, bien plus qu'un paquet ArchLinux et je te raconte pas pour eopkg…

          C'est bien de le répéter à l'envi. Maintenant, il faudrait probablement citer avec une vraie comparaison, comme ça, on pourrait peut-être voir s'il y a une raison derrière cette complexité.

          • [^] # Re: PKGBUILD

            Posté par (page perso) . Évalué à 4.

            C'est bien de le répéter à l'envi. Maintenant, il faudrait probablement citer avec une vraie comparaison, comme ça, on pourrait peut-être voir s'il y a une raison derrière cette complexité.

            Avec Debian je ne sais pas mais avec Arch il faut avouer que la création de paquets est plutôt simple :
            https://github.com/nokomprendo/tuto_fonctionnel/tree/master/tuto_fonctionnel_18/#cr%C3%A9er-ses-propres-paquets

            • [^] # Re: PKGBUILD

              Posté par (page perso) . Évalué à 1.

              Oui mais il n'y a pas de verification de qualité et autre qui sont fait pour la construction de deb et de rpm. J'en avais parlé une fois avec des gars de mageia à l'époque, je disais que je ne pigeais pas que RPM et DEB soient si complexes et chiant a faire par rapport a des distributions comme arch, nutyx ou 0linux (qui etait encore plus simpliste), on m'avait dit que c'etait dû du fait que ces paquets n'avaient aucune vérification de qualité et autre.

              Je ne trouverais plus la discussion car elle remonte a bien vieux (2015).

              • [^] # Re: PKGBUILD

                Posté par (page perso) . Évalué à 1.

                Qu'entends-tu par "vérification de qualité" ?
                J'ai soumis quelques paquets pour Voidlinux et il y a pas mal de vérifications (j'imagine que ça doit être pareil pour Arch). Le fichier de packaging lui-même est vérifié avec un outil de type lint. Puis l'outil de construction de paquet vérifie l'archive, le checksum, les dépendances, les patches, la compilation, l'installation, les so-bumps… On peut construire le paquet dans un environnement isolé (en bootstrapping) et pour différentes architectures (en cross-compilation). Enfin, quand on soumet le paquet à l'upstream (via un simple PR), tout est revérifié par un système d'intégration continu (travis CI) et relu par les mainteneurs de la distrib.

                • [^] # Re: PKGBUILD

                  Posté par (page perso) . Évalué à 2. Dernière modification le 25/04/18 à 14:59.

                  Vérification de qualité, ça veut dire forcer les fichiers de conf à respecter la philosophie de la distribution. Il y'a d'autres checks mais les plus chiant à corriger sont ceux là car non liés à la forme de ton paquet.

                  Comme ArchLinux respecte l'upstream, il n'y pas ce besoin…

                  • [^] # Re: PKGBUILD

                    Posté par (page perso) . Évalué à 1.

                    Vérification aussi que le paquet ne casse rien dans l'archive debian, il faut que le paquet s’insère proprement sans faire le boxon, là ou arch s'en fout de ce que j'ai compris.

                    Contrôle de qualité norme debian, est ce que les fichiers vont bien uniquement là où c'est convenue dans la charte… Est ce que la licence est bien présente… Bref, des contrôles internes a la distribution.

                    Arch peut respecter l'upstream c'est pas pour autant que c'est propre… Qui n'a jamais vu des choses s'installer dans /opt? pour quelle motifs?

                    • [^] # Re: PKGBUILD

                      Posté par (page perso) . Évalué à 1.

                      Contrôle de qualité norme debian, est ce que les fichiers vont bien uniquement là où c'est convenue dans la charte…

                      Si tu ne connais pas déjà, tu devrais regarder du côté de Nixos.
                      Nixos essaie de vraiment résoudre ces problèmes, là où Debian se contente d'essayer de les éviter.

                    • [^] # Re: PKGBUILD

                      Posté par (page perso) . Évalué à 2.

                      là ou arch s'en fout de ce que j'ai compris.

                      À tel point que si tu n’as pas lu l’entièreté des articles sur archlinux.org avant chaque mise à jour, il y a une chance sur deux que tu n’es pas suivi la liste d’actions manuels qui sont nécessaires pour mettre a jour.

                      • [^] # Re: PKGBUILD

                        Posté par . Évalué à 2.

                        En pratique :

                        • J'ai archlinux.org dans mon lecteur de flux RSS
                        • Avant chaque mise à jour, un coup d'œil rapide pour vérifier que je n'ai pas loupé une mise à jour du flux (c'est facile : s'il y a eu une mise à jour, le flux est affiché en gras)
                        • Si action manuelle, une commande clé en main est généralement fournie
                        • Ça prend environ 20 secondes par mise à jour

                        Ça, ce sont les sources. Le mouton que tu veux est dedans.

                        • [^] # Re: PKGBUILD

                          Posté par . Évalué à 1.

                          Qu'il soit possible de s'en accommoder personne n'en doute, mais ça pose des problèmes.

                          Mon expérience avec gentoo (qui a un peu cette approche là) ça a était :

                          • installation stage 3
                          • mise à jour dans la foulée
                          • environnement cassé
                          • réparation en suivant le site avec une autre machine du coup
                          • → formatage du disque pour aller voir ailleurs

                          Personnellement, j'ai un outil devant moi qui est fait pour l'automatisation, si on a inventé ces trucs là et si c'est si populaire c'est justement pour cette capacité. Il n'est pas très compliqué d'avoir un gestionnaire de paquet qui va scruter le site qui annonce ces trucs là et qui te l'annonce s'il fait la mise à jour qui est en cause. Debian le fait pour un certain nombre de choses. Ça permet d'avoir l'information qui est poussé vers toi au moment le plus opportun plutôt que de devoir chacun réimplémenter son propre workflow (comme celui que tu nous présente). En plus ça n'interdit pas d'avoir son propre workflow. C'est juste la différence entre s'intéresser à l'utilisabilité ou pas.

                          Si je suis si malin pourquoi je l'implémente pas ? Parce que je me fou d'Arch, j'utilise Debian et j'en suis satisfait.

                        • [^] # Re: PKGBUILD

                          Posté par (page perso) . Évalué à 2.

                          En pratique :

                          En pratique, sur Debian, j’utilise unattended-upgrades.

                      • [^] # Re: PKGBUILD

                        Posté par . Évalué à 1.

                        À tel point que si tu n’as pas lu l’entièreté des articles sur archlinux.org avant chaque mise à jour…

                        Ah bon? Un jour, si tu veux utiliser Arch, la mise à jour est simple et elle se fait en quelques secondes:
                        pacman -Syu

                    • [^] # Re: PKGBUILD

                      Posté par (page perso) . Évalué à 2.

                      Mwai, enfin si tu veux parler QA, je pense que Debian est autant à la ramasse que ArchLinux. Parce que vérifier qu'un paquet ne casse rien, Debian ne le fait clairement pas (où alors je suis à la rue), c'est pas comme si une mise à jour de Jessie non testée avait cassé un crontab de php.

                      De ce côté là seul Fedora et OpenSUSE font le job (grâce à OpenSUSE d'ailleurs).

  • # Compliqué

    Posté par (page perso) . Évalué à 3.

    Je ne cherche pas à troller, juste à donner mon avis sur mon ressenti et à avoir des commentaires

    Je n'utilise pas Debian, cependant j'ai déjà regardé quelques documentations pour faire des paquets debian. Je trouve ça extrêmement compliqué. En effet, il y a plusieurs fichiers dont la plupart ont une syntaxe différente :

    • rules : Makefile,
    • control : syntaxe personnalisée, simple cependant,
    • changelog : syntaxe différente.

    Ensuite, vient le nombre de commandes : deb-* dh_*, dpkg, … est-ce vraiment possible de tout mémoriser ? Combien de temps cela prend-il ?

    J'écris quelques packages pour fedora (via mon dépôt COPR), je trouve les .spec tellement simple, en quelques lignes on a un paquet 100% fonctionnel avec une seule et unique syntaxe et commande rpmbuild. Les paquets Arch sont aussi plutôt simple.

    J'aimerais bien avoir l'avis d'un développeur debian pour qu'il me dise son propre ressenti sur les paquets Debian.

    l'azerty est ce que subversion est aux SCMs

    • [^] # Re: Compliqué

      Posté par . Évalué à 3.

      J'utilise arch pour le bureau, et debian pour des serveurs, et je souffre beaucoup pour modifier des --enable dans des paquets debian, cela m'a pris plusieurs semaines de recherches, et pas mal de difficulté à comprendre comment tout fonctionne. Le nombre d'outils disponibles dpkg-* c'est affreux. Le "design" de debian me fait honte, devant la simplicité et la beauté d'organisation d'arch. Je vois que je ne suis pas le seul.

      J'en suis à me demander si je vais continuer d'utiliser debian. Mais ce que je trouve encore pire dans toute cette histoire, de découverte de comparaison, c'est cette communauté linuxfr, on va encore dire que je suis hors sujet ou je ne sais quoi, mais dès qu'on lance un pique pour faire réfléchir, critiquer, donc dialoguer sur des problématiques linuxiennes. Il faut toujours qu'il y ait un boulet (d'une lourdeur) qui se ramène en disant, il TROLL, IL TROLL C'EST UN MÉCHANT ! L'unilatéralité d'un dialogue c'est un manque de liberté. Devoir préciser à chaque fois, c'est pas un troll…

      Sur ce je retourne dans ma galère pour modifier des --enable et remercie l'auteur du journal pour m'avoir aidé (un peu) à comprendre cette horreur.

      • [^] # Re: Compliqué

        Posté par (page perso) . Évalué à 3.

        Je répondrais au deux commentaire dans celui-là.

        En faite il y a plusieurs manière de faire des paquets, du plus simple et automatisé à la manière bonhomme barbu avec pizzas a la main, en prenant celle que j'utilise, c'est a dire dh_make tous les fichiers du dossier debian sont fait, il ,ne reste plus qu'a les remplir, je remplis tous avec un simple editeur sauf le changelog que j'utilise dch. Apre pour fabriquer le paquet c'est debuild.

        Apres, je trouve, c'est perso, que les RPM sont plus simple mais sont moins unniverselles que les DEB, je m'explique, je fais quelques paquets pour openSUSE, avec OBS (et osc), je suis souvent incapable de comprendre d'où vient mes ennuis quand j'essaye de faire un paquet pour plusieurs distributions RPM, aussi je suis souvent emmerdé en reprennant des spec de fedora ou autres pour opensuse et le contraire et vrai aussi, par exemple un paquet sous rosa m'interesse pour le faire sous fedora et opensuse et bien non ça merde… Je parle pas uniquement des buildrequire ou des deps, il suffit juste de donner le bon nom, je parle de la partie build ou install. Alors que sous debian mais peu importe en faite, je suis capable de le faire, je prends chez ubuntu des sources (je regarde quand meme ce qui se passe dedans) et puis je build pour ma debian.

        Je me doute qu'il doit y avoir une methode pour que le spec soit unniversel mais comment? Là je pose une vraie question, comment faites vous de votre coté?

        Par exemple actuellement, j'essaye de faire rocksndiamonds pour opensuse en 4.1, je prends le spec de fedora ou de n'importe quelle distribution RPM, et ensuite que dois-je changer dedans a part les noms des deps et des buildrequires?

        @ dastious , si ça pet t'aider il y a le premier billet, qui explique un peu tous les fichiers, https://passiongnulinux.tuxfamily.org/post/construire-des-paquets-deb-pour-debian/

        Dit moi ce que tu en penses:)

        • [^] # Re: Compliqué

          Posté par (page perso) . Évalué à 5.

          Il faut quand même noter que les distributions majeures qui utilisent deb sont issues de Debian, c'est donc normal que les noms de paquets ou les options de compilatio, par exemple, soient les mêmes (ou très proche) par exemple. Alors que Fedora et Suse n'ont rien à voir au niveau de la parenté.

          « 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: Compliqué

            Posté par (page perso) . Évalué à 3.

            Tout à fait, il ne faut pas mélanger les problèmes venant du format lui même avec les conventions de nommage des distributions (découpage des paquets, convention de nommage, choix des noms d'un paquet comme kernel ou linux, httpd ou apache…).

          • [^] # Re: Compliqué

            Posté par (page perso) . Évalué à 1.

            Oui oui je comprends bien que ça venait de la la "compatibilité", mais pourquoi les specs a part la partie nominatives des paquets (require, deps, ect…) ne sont que peu compatible, comment savoir ce qu'il faut changer?

        • [^] # Re: Compliqué

          Posté par (page perso) . Évalué à 3.

          En même temps Fedora n'est pas OpenSUSE.

          Je peux très bien faire une distribution basée sur dpkg et avec le même genre d'incompatibilités. L'avantage pour Debian, c'est que toutes les distros utilisant dpkg sont des Debian, Ubuntu y compris.

      • [^] # Re: Compliqué

        Posté par (page perso) . Évalué à 5.

        Lancer une pique, ça n'encourage pas la discussion. Un point important est de montrer que tu connais le système que tu critique et que tu ne fais pas dans le gratuit. Typiquement, tu dis qu'il faut des semaines pour changer les --enable. Or, si je recherche debian override configure, le premier lien est une question sur stackexchange qui donne le fichier (pour le format, la première ligne indique que c'est appelé par make et la target à ajouter/modifier.

        Et si tu veux la structure globale d'un paquet, le guide du nouveau mainteneur Debian explique ça bien et il ne faut pas des semaines pour le parcourir.

        « 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: Compliqué

          Posté par . Évalué à 1.

          Mon reproche est contrairement à d'autres distrib où je peux regarder les fichiers de package, et déduire facilement comment rebuild en quelque heure, alors que j'ai déjà du travail en cours, Debian me demande de m'arrêter, et de comprendre un nouveau fonctionnement tout à fait différent, et plus complexe que la moyenne, donc oui ça demande du temps de travail en plus, surtout si on veut faire les choses propres. J'espère qu'au bout de quelques années j'y trouverais des avantages, j'espère.

Suivre le flux des commentaires

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