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 seb95 (site web personnel) . Évalué à 3. Dernière modification le 23 avril 2018 à 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 alkino . É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 barmic . É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 freem . É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.
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 Maderios . Évalué à 4.
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 gnumdk (site web personnel) . É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 seb95 (site web personnel) . É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 gnumdk (site web personnel) . Évalué à 4.
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.
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 seb95 (site web personnel) . É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 gnumdk (site web personnel) . É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 seb95 (site web personnel) . É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 gnumdk (site web personnel) . Évalué à 2.
Je pense que tu sous estimes le nombre d'applications dépendant de webkitgtk…
[^] # Re: PKGBUILD
Posté par Anthony Jaguenaud . Évalué à 2.
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 kna . Évalué à 2.
La version stretch est aussi vulnerable d'après : https://security-tracker.debian.org/tracker/source-package/webkit2gtk
Si on clique sur un des CVE, on voit :
Tu peux aussi voir tous les paquets de stable affectés : https://security-tracker.debian.org/tracker/status/release/stable
[^] # Re: PKGBUILD
Posté par gnumdk (site web personnel) . Évalué à 2.
C'était volontaire pour montrer que la 2.20 ne fait même pas parti des backports et que donc il n'y pas moyen d'avoir une debian stable sécurisée (pour la bureautique hein).
[^] # Re: PKGBUILD
Posté par freem . Évalué à 2.
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?
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).
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 nokomprendo (site web personnel) . Évalué à 4.
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 seb95 (site web personnel) . É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 nokomprendo (site web personnel) . É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 gnumdk (site web personnel) . Évalué à 2. Dernière modification le 25 avril 2018 à 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 seb95 (site web personnel) . É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 nokomprendo (site web personnel) . Évalué à 1.
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 Anonyme . Évalué à 2.
À 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 Liorel . Évalué à 2.
En pratique :
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: PKGBUILD
Posté par barmic . É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 :
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 Anonyme . Évalué à 2.
En pratique, sur Debian, j’utilise
unattended-upgrades.[^] # Re: PKGBUILD
Posté par Maderios . Évalué à 1.
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 Anonyme . Évalué à 3.
Je préfère
yaourt --sucre.[^] # Re: PKGBUILD
Posté par gnumdk (site web personnel) . É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 David Demelier (site web personnel) . É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 :
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.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Compliqué
Posté par dastious . É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 seb95 (site web personnel) . É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 claudex . É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 Renault (site web personnel) . É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 seb95 (site web personnel) . É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 gnumdk (site web personnel) . É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 claudex . É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é parmakeet 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 dastious . É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.
[^] # Re: Compliqué
Posté par claudex . Évalué à 4.
L’avantage que je trouve, c’est quand le paquet devient gros, c’est plus facile de naviguer dans plusieurs fichiers que dans un seul. Si on prend le paquet
nginxchez Debian, le fichier rules fait déjà plus de 150 lignes. Le fichier control en fait près de 400 et le fichier changelog en fait plus de 2200. C’est sûr que c’est possible de bosser dans un seul fichier avec tout ça, mais c’est quand même plus pratique de les avoir séparés vu qu’ils n’ont rien à voir ensemble. Et je ne compte pas les fichiers install.Il faut avouer que ça vient de la découpe en multiple paquets, c’est un avantage que je trouve à Debian, mais je comprends que ça ne déplace pas les foules non plus.
Il faut avouer que c’est aussi lié au format verbeux. Le specfile Fedora pour nginx fait 800 lignes.
Pour un petit projet vite fait, le format deb est plus contraignant qu’autre chose de mon point de vue.
« 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 seb95 (site web personnel) . Évalué à 1. Dernière modification le 25 avril 2018 à 15:03.
pour changer ou ajouter une option c'est dans le fichier rules.
https://www.debian.org/doc/manuals/developers-reference/
https://www.debian.org/devel/
https://www.debian.org/doc/debian-policy/
https://debian-facile.org/doc:mentors:retroportage
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.