Michaël a écrit 2935 commentaires

Maintenant, je soupçonne que cela permette moins choses en contrepartie, comme l'indication formelle des licences utilisées

Le Portfile précise la license utilisée

license             CeCILL-B

l'ajout de patchs spécifiques annotés

Je ne sais pas si tu as des chose particulières en tête avec patch annoté mais oui on peut ajouter des patchs — et tous les patchs peuvent être annotés, il suffit d'écrire devant le premier chunk.

le suivi des versions du logiciel amont et des révisions de l'empaquetage, avec lien avec le système de suivi de bugs de la distribution

Les ports MacPorts sont gérés dans un repository Subversion, donc en examinant les commit logs du Portfile j'ai une correspondance claire entre les révisions du Portfile et les versions upstream.

Le lien avec le système de suivi de bogues de la distribution est fait par trac cela ressemble à ca:

• https://trac.macports.org/changeset/125182
• https://trac.macports.org/report

Si les rapports préfabriqués ne suffisent pas on peut faire des requêtes complexes sur la base de données de tickets. Tous les tickets afférants à un port ont le nom du port dans leur champ Summary. Est-ce que ça suffit?

les notifications automatiques de la présence d'une nouvelle version amont

Oui c'est le travail que fait port livecheck. Bien-sûr il faut peut-être un peu le configurer, mais c'est forcément le cas sous Debian aussi.

avec automatisation du téléchargement et de leur intégration dans ton empaquetage

Je ne suis pas sûr de comprendre à quoi tu fais référence, mais j'ai l'impression que c'est une fonction qui n'a de sens ou d'utilité que pour un maintainer Debian. Je n'ai pas besoin d'intégrer quelque chose dans mon empaquetage. Et puis comme télécharger un fichier source est à peu près aussi facile que de taper la commande mv dans un terminal, je trouve un peu spécieux d'arguer là dessus.

la définition éventuelle des fichiers à mettre dans tel ou tel paquet binaire dans le cas d'une séparation en plusieurs paquets

Ce n'est pas pris en charge par MacPorts à ma connaissance mais d'une part je n'ai pas utilisé cette fonction dans la préparation de mon package Debian et c'était quand-même compliqué; d'autre part, dans les système de ports on modifie la sélection des fichiers installés en changeant les options de compilation (les variants dans la MacPorts-lang).

J'en oublie sans doute, mais tout ça pour dire que oui, l'empaquetage Debian est plus complexe, mais que tout y a une raison d'être.

Après ce petit bilan j'ai surtout l'impression qu'il est plus complexe tout court.

Dans les systèmes de ports du monde BSD, soit FreeBSD, NetBSD, OpenBSD et MacPorts je crois savoir que celui de FreeBSD est le plus mal fichu de tous — mais n'ayant pas utilisé ni NetBSD ni OpenBSD, il faut mettre de très gros guillemets autour de mon “je crois savoir” — et pourtant il est bien plus accessible pour le maintainer que le système de packages de Debian à cause d'une bonne documentation bien à jour.

Peut-être que si tu t'étais contenté de simplicité, ça serait passé

Je parle seulement de la procédure d'écriture pas du système de gestion de paquets en elle-même.

mais pour rajouter qualité dans ta phrase, il fallait attendre vendredi…

Impossible, vendredi je suis en vacances! :-)

Et à propos, ça y est c'est intégré dans MacPorts — devel/bsdowl !

Oui mais du coup tu perd le lien entre une version des sources et ton packaging

En général j'écris le numéro des versions que je package dans mes commit logs donc le lien n'est pas perdu.

Sincèrement l'espace disque est un faux problème,

Complètement d'accord: c'est inesthétique mais ça n'a pas de grosses conséquences pratiques.

Quelle est la façon intelligente d'intégrer le dossier ./debian aux sources? Si je veux écrire dans le ChangeLog un message du style Update to version 2.3, this closes Debian ticket XXXXX je dois terminer le package Debian avant de publier la version, ce à quoi je ne veux pas être contraint. Du coup, comment ça marche? On crée une branche debian dans laquelle on merge masterà chaque nouvelle version?

C'est un peu comme si tu nous disais qu'il est difficile d'éditer un fichier parce qu'entre vim, emacs, gedit, kate et sublime text il y a de quoi se perdre

J'ai oublié d'encadrer mon message précédent avec <sarcasme> et </sarcasme>, désolé!

(N'empêche que dselect est toujours installable!)

C'est encore plus facile! Je suis le trèstaentueuxauteur de bsdowl une famille de scripts pour BSD Make qui marchent sous FreeBSD et Darwin, et apparemment Debian aussi.

Je me suis dit que ce serait sympa de faire un package pour Debian.

En gros pour l'installation, il s'agit de recopier une tripotée de fichiers dans ${PREFIX}/share/mk.

<pub>
https://bitbucket.org/michipili/bsdowl

Voici la liste des “petits trucs en plus” de mes macros, dans le cas de la préparation de documents TeX.

• À la fin de la compilation, une liste des erreurs LaTeX est affichée.
• Le bon nombre de compilations pour l'index etc.
• Un mode DRAFT qui compile une seule fois et publie (installe) le fichier avec un timestamp, pratique pour l'envoyer à ses collaborateurs ou relecteurs (et plus pertinent pour eux qu'une référence RCS).
• Compilation des figures avec METAPOST, ce qui est très cool, et de plus les fichiers image sont effacés par realclean mais pas par `clean' (ce qui est adapté pour une publication pour arXiv par exemple).
• Compilation des fichiers de bibliographie, distingo semblable pour clean et realclean.
• Gestion simplifiée de la variable TEXINPUTS pour avoir facilement ses fichiers répartis dans plusieurs dossiers.
• Gestion des réglages d'impression PostScript définis grâce à texconfig

Il y a des indications plus détaillées sur le wiki: https://bitbucket.org/michipili/bsdowl/wiki/ProduceLaTeXDocuments (in inglishe) Peut-être que je vais en faire une version “dépêche” pour LinuxFR lorsque j'aurais packagé ça dans Debian.
</pub>

L'art de répondre à côté. Le sujet ce n'est pas ce que toi tu sais faire. Le sujet c'est comment le savoir, où le savoir et en combien de temps.

Exactement, c'est ça le nœud du problème et je crois avoir assez démontré (en tout cas j'ai donné des exemples et des URLS, j'ai bien mouillé la chemise!) que pour FreeBSD et MacPorts cette documentation existe est à jour et a un gros tampon officiel qui clignote dessus qui fait qu'il est impossible de ne pas la trouver si on cherche de la documentation sur le sujet.

Perso si c'est aussi simple à compiler je peux le faire en une demi-heure.

En ne sachant rien, en partant de la documentation officielle? Je veux bien voire ça! D'abord, c'est laquelle la documentation officielle.

• https://wiki.debian.org/IntroDebianPackaging ne parle pas de dh_make
• https://www.debian.org/doc/manuals/maint-guide/first.en.html parle de dh_make mais si je suis la section 2 pas à pas, et bien à la fin je n'ai pas fait grand'chose alors qu'avec MacPorts en lisant un texte trois fois moins long j'ai déjà presque fini

(Pour les détails, c'est plus bas sur cette page.)

Question au hasard. Tu as un expérience avec d'autres systèmes de distribution de logiciels tiers que celui de Debian? Par exemple FreeBSD ou MacPorts? Que tu connaisses très bien le système de packages de Debian n'est pas incompatible avec le fait que le système soit inutilement compliqué et très mal documenté.

Je suis loin d'être d'être d'accord avec tes arguments (voir les autres commentaires).

Je n'ai pas analysé ou argumenté très sérieusement — j'ai écrit un journal qui dénonce grave mais j'ai oublié de l'écrire au début, mea culpa maxima — mais si j'écris un port pour FreeBSD j'utilise un programme, make et une documentation, le Porter's Handbook, si j'écris un port pour MacPorts j'utilise deux programmes port et openssl (pour calculer les checkusms) et une documentation, le MacPorts Guide. Et dans le cas facile, j'ai une procédure simple à suivre et j'écris un fichier, le Makefile ou le Portfile.

Si j'écris un package pour Debian, c'est un peu plus flou, on va dire! Et du coup même le cas simple est assez difficile.

Pour faire le port MacPorts c'et tellement rapide que je te décris la procédure pas à pas ici:

1. J'ouvre le guide https://guide.macports.org avec toute la doc dans une bonne grosse page HTML, pas très subtil, mais pratique pour la fonction recherche de mon Browser.

2. Armé de mon œil de lynx, je descends à la section 4.2, https://guide.macports.org/#development.creating-portfile

3. Je recopie le contenu des lignes 2-14, mutatis mutandis, je laisse tomber la ligne 1 qui est optionnelle. Il ne s'agit que de champs informatifs, genre qui, que, quoi, dont, où, et l'URL où télécharger la source. J'ai déjà presque fini, ça a duré maximum 1/4 d'heure.

4. Je calcule les checksums de la distribution avec SSL. Comme je n'ai pas éxécuté la commande dans un C-u M-! de Emacs, j'utilise une vieille technique de byteninja pour faire un copier-coller des checkums dans l'éditeur. J'insiste là-dessus, parceque c'est la partie la plus technique de la procédure.

5. Comme mon port utilise bsdmake pour compiler et que mon intuition de byteninja me dit que je vais sûrement avoir besoin d'écrire bsdmake quelque part dans mon Portfile donc je lance une recherche du mot-clef BSD dans ma grosse page web de documentation: il y a 8 correspondances, la troisième me paraît bien juteuse:

build.type
Defines which build software is required and sets ${build.cmd} accordingly. The available options are BSD Make, GNU Make, and Xcode.

Default: default (the default Make on the current platform)

Values: default bsd gnu xcode

Example:

build.type          bsd

Bon très bien, ajoutons une ligne build.type bsd au Portfile.

1. Je teste, installe, désinstalle, tout marche nickel. C'est presque magique! J'en suis à 1/2 heure maxi.

2. Je veux uploader mon port pour que mes copains sous MacPorts puissent l'utiliser. Comme je ne trouve pas tout de suite la section adéquate dans le sommaire je réutilise la fonction recherche dans ma bonne grosse page HTML et je tombe rapidement sur le paragraphe adéquat https://guide.macports.org/#project.contributing qui décrit une procédure propre et limpide.

Voilà j'ai bossé 3/4 d'heures en partant des informations suivantes: le site web de mon projet à porter et le manuel de MacPorts et en ignorant potentiellement tout de la procédure. Et j'ai fini!

La procédure d'écriture d'un package pour Debian est objectivement à plusieurs téra-années-lumières de ce niveau de qualité et de simplicité.

Sans oublier les multiples commandes pour installer le paquet! apt-get, dselect, aptitude, synaptic. Je ne suis pas utilisateur de Debian, donc je n'ai cité que les plus connus!

Je ne vois pas en quoi ça pose un problème

Cela pose problème si on veux ne versionner que les fichiers de mainteneur dans ./debian parceque on ne peut pas faire de checkout d'un sous-répertoire avec git. On peut versionner le tout, sources + fichiers de mainteneur, mais ça fait un rapport signal/bruit assez faible… Je sais bien que le prix du ko de disque dur a beaucoup baissé depuis 20 ans, mais bon, quand-même.

Merci pour le lien PackagingWithGit qui a l'air de contenir des infos bien utiles.

Mais je suis d'accord un paquet debian la marche pour faire des paquets Debian est haute et la profusion d'outils pour aider en est une démonstration AMHA (inutile de simplifier ce qui est déjà simple).

Très franchement, il s'agit d'un système dont la procédure d'installation est

./configure
bmake
bmake install

et comprendre pourquoi j'ai besoin de plus d'une heure pour faire avaler ça à Debian est absolument au dessus de mes forces!

Pourquoi ? Soit, voyons ça point par point.

C'est gentil!

Oui, l'avantage c'est que c'est naturel. On bosse dans le répertoire des sources, après tout c'est là qu'on fait la compilation.

Sauf que dans tous le processus tel qu'il est décrit, je ne lance la compilation qu'indirectement en utilisant un outil dont le… pardon, les fichiers de configurations sont dans ./debian donc du coup pour moi ce serait plus naturel de travailler dans ./debian. Mais bon comme les packages sont crées dans ../ c'est sympa, on est bien au centre!

comme mon krims-krams est en RCS
Bon, je vais me forcer à continuer à lire malgré cet archaïsme ahurissant.

Ah oui, j'ai un petit problème, lorsque j'écris, je confonds toujours SCM (le terme générique) et RCS (un logiciel bien archaïque). Mais peut-on prendre au sérieux un journal qui dénonce grave™ lorsqu'il est trop précis? Peut-on?

La meilleure stratégie est à mon avis de versionner le tout (sources amont + répertoire debian/),

Excellent! Ma procédure d'installation est

./configure
bmake
bmake install

Cela fait 32 octets! En versionnant aussi les sources upstream je peux directement passer à 5Mo (repository git) ou bien quelques ko (en mode vendor drops) — l'avantage saute tout de suite aux yeux!

Ensuite je dois écrire un 9 dans le dossier debian/compat. Qui ne contient que cette seule donnée.
Ça s'appelle du versionnement de format, tu trouveras ça dans plein de trucs, même dans le format tar tiens.

Oui merci le problème n'est pas d'avoir du versionnement de format. Quelle est la raison pour laquelle ce 9 ne va pas dans le fichier control par exemple? C'est vraiment pour le plaisir d'avoir un fichier de plus.

Quant au fait d'avoir un changelog d'empaquetage, ça n'a rien d'anormal.

Oui bien-sûr que ça n'a rien d'anormal mais le petit problémou c'est que c'est expliqué dans le mauvais ordre dans le guide de packageur Debian pour les gens pressés. Et puis il y a écrit que ce fameux fichier ChangeLog a un format si spécial qu'il faut mieux l'éditer avec un programme dédié.

Mais toujours est-il que, pour faciliter la vie des gens qui utilisent des systèmes de gestion de version pour leur empaquetage, il existe justement des outils qui remplissent automatiquement le changelog Debian à partir de celui du gestionnaire de version. Enfin, ça existe pour les systèmes de versionnement actuels, mais pour RCS c'est peu probable.

Il existe un peu trop d'outils pour faciliter la vie des gens, je trouve.

Alors, ce fichier rules, c'est effectivement un Makefile, qui doit avoir des cibles précises, genre binary, build, clean, etc. (c'est documenté dans la charte Debian).

C'est le problème, tout est documenté un peu partout, donc forcément on passe à côté de la documentation. Pour écrire des ports sous FreeBSD ou MacPorts il y a une documentation officielle et à jour avec la version courte ”toi aussi prépare ton paquet en vingt-six minutes” et la version longue ”tu es tombé sur un petit facétieux, voyons comment l'intégrer gentiment au système.”

qui délègue toutes les étapes à dh, un ensemble de scripts prévus pour essayer toutes les méthodes connues avec les systèmes de constructions usuels

C'est assez facile de le mettre dans les choux l'ami dh il suffit d'utiliser BSD Make (bmake sous Debian) et il faut écrire les règles à la main et j'ai fait ça à coup de devinettes puisqu'il y a trop de documentations différentes.

Ah, mais c'est qu'il ne suffit pas de faire un paquet qui marche, il faut faire un paquet propre, notamment correctement documenté et respectant les conventions, par exemple la FHS. Si c'est tout ce que tu avais fait, il manquait notamment le fichier debian/copyright décrivant la ou les licences utilisées dans ce paquet.

Que les choses soient claires. Je parle d'un logiciel dont la procédure d'installation est

./configure
bmake
bmake install

qui respecte tout, qui est documenté et tout, et tout! Mais en suivant la procédure décrite ici:

https://wiki.debian.org/IntroDebianPackaging

on déclenche 3-4 erreurs de lintian à cause de pratiques obsolètes!

Mal expliqué, ça c'est un autre problème, sur lequel on peut aider.

Oui, les gens qui ne savent pas comment ça marche sont probablement les mieux placés, je suppose.

Bilan, si je veux packager un logiciel assez bien standardisé dont la procédure d'installation est

./configure
bmake
bmake install

sous FreeBSD ou sous MacPorts, je peux le faire en 1 heure (en comptant large) en suivant bêtement la documentation officielle; sous Debian c'est autre chose!

En tout cas ça valait le coup d'écrire un journal qui dénonce grave!

Je crois que c'est plutôt “Keep it simple, stupid!” sinon la blague avec “Kiss me, stupid!” ne marche pas trop bien.

Attaquons le problème à la racine : Tu es prêt à payer combien pour faire une doc ? Ben oui, parce que visiblement tout le monde veut faire un paquet mais personne la doc.

— Salut, j'ai inventé un nouveau tournevis, si tu veux je peux te montrer comment les fabriquer tu pourras l'utiliser aussi.
— Ah c'est toi, tu tombes bien, j'avais besoin de quelqu'un pour m'aider à ranger ma cabane à outils.
— (Soupir!)

git, systemd et le système de packaging debian sont des choses très complexes et dont l'accessibilité aux nouveaux est plus longue que la concurrence. C'est un fait.

Pour systemd je ne sais pas — je suis sous FreeBSD — mais pour git et le reste ke te rejoins. git est très difficile pour les débutants à cause de son interface tout pourrie (genre git mv mais git branch -m mais git remote rename pour les moins-gitistes d'entre nous, ça sert à renommer un fichier, une branch ou un alias de repository) et à cause de ses opérations qui ne correspondent pas au modèle de l'utilisateur (il faut souvent traduire une action en 2 ou 3 commandes). CVS ça a beau être tout pourri au niveau des fonctionnalités, cela a le mérite de la simplicité: check-in, update, check-out, et les branches, oublie les!

Il faut que tous les systèmes automatiques puissent traiter le paquet, donc il faut qu'il suive un certain nombre de règles. Et comme les règles évoluent, il faut déclarer à quelle version (d'où le compat)

Oui bien sûr que c'est utile d'écrire le numéro de version. Ce qui semble inutile c'est d'écrire ce format dans un fichier à part. À quoi ça sert de ne pas l'écrire dans le fichier debian/control? C'est vraiment pour le plaisir d'avoir un fichier en plus!

Par exemple, le fichier changelog sert à savoir quel est la version du paquet et quels bogues il ferme.

Ce ne serait pas plus simple de mettre tous ces fichiers debian/* dans un SCM, comme ça on aurait l'historique et la possibilité de remonter le temps facilement.

Forcément, un simple port qui fait configure-make-make install est plus facile…

En fait c'est le gros point faible du système et de la documentation de Debian: c'est que même le cas facile est compliqué! Pour une tarball qui s'installe proprement avec la procédure canonique (configure, build install, pour ceux qui dorment, près de la porte), comprendre que l'écriture d'un package pour Debian dure plus d'une heure quand on ne connaît rien au système est absolument au dessus de mes forces.

(bien qu'avoir la liste des processus devrait être un minimum, tout comme sur une voiture tout le monde devrait savoir contrôler le niveau d'huile).

La deuxième tâche est expliquée dans la notice d'utilisation de ta voiture. Au moins!

WTF !???!? Je rate quelque chose ou c'est un bon gros NIH
des bois ?

Quand tu gères un parc de machines, avoir une distrib personalisée te permets d'avoir ta distribution de base toute bien configurée, donc:

1. Avec tes repositories qui copient les paquets publics et ajoutent tes paquets privés pour le fait maison.
2. Avoir les clefs SSH des administrateurs déployées sur toutes les machines (genre le „backup officer“).
3. Avoir de base, tout les service réseau (client NFS, client répertoire, etc.) préconfigurés.

Bien-sûr tu peux tout faire avec un script, mais je pense que dès que quand tu es dans un système où tu as beaucoup de turnover (la recherche, c'est beaucoup de CDD) et que tu files une machine fraîchement installée à tous les nouveaux venus, et bien, il y a intérêt à avoir ta procédure “je mets la galette dans la machine, et j'ai fini”.

J'ai acheté un moulin a café manuel pour… réduire ma consommation de café! Ça marche nickel, depuis, je ne bois plus que deux cafés par jour!

Les pages de wiki sont bien faites et didactiques,

Merci!

par contre il y a pas mal de liens qui ne fonctionnent pas, sans doute que c'est prévu d'être étendu prochainement

C'est bien ça. Prochainement. :)

On dirait presque du Rafi Haladjian le début!

http://cristal.inria.fr/~weis/info/haladjian.pdf

du "PAN PAN"!

Cette section m'a amusé. Écrivant beaucoup de courriers en ce moment, j'ai trouvé pratique de les mettre tous dans le même répertoire. La date de création préfixe le nom de toutes les sources, et mon makefile contient la cible last, qui formate le dernier document créé – celui en cours dans la très grande majorité des cas.

Oui, les lettres c'est un peu spécial parcequ'en général une lettre correspond à un fichier. Pour les documents plus complexes c'est en général une bonne idée de suivre la règle “un document correspond à un dossier”.

Pour les lettres, je m'organise exactement de la même façon que toi, j'utilise aussi la date comme préfixe, avec un dossier chaque année. :)

Cette info est l'exacte inverse des retours d'expérience qu'on avait eu fin 2013 sur Limux et Munich.

Il y a eu des éléctions municipales et un changement de maire en 2014. Tiens, tiens… Il semblerait qu'on ait affaire à une déclaration tonitruante pour critiquer le bilan de la dernière mandature. L'état des choses est que le maire adjoint (de droite) a confirmé à un journaliste (d'un journal de droite) que l'idée était dans l'air mais guère plus: on est assez proche du ballon d'essai et on est assez loin d'avoir une date de réalisation; et ce n'est même pas sûr qu'ils aient déjà fait une estimation du cout du changement…

Voici la liste des “petits trucs en plus” de mes macros:

• À la fin de la compilation, une liste des erreurs LaTeX est affichée.
• Le bon nombre de compilations pour l'index etc.
• Un mode DRAFT qui compile une seule fois et publie (installe) le fichier avec un timestamp, pratique pour l'envoyer à ses collaborateurs ou relecteurs (et plus pertinent pour eux qu'une référence RCS).
• Compilation des figures avec METAPOST, ce qui est très cool, et de plus les fichiers image sont effacés par realclean mais pas par `clean' (ce qui est adapté pour une publication pour arXiv par exemple).
• Compilation des fichiers de bibliographie, distingo semblable pour clean et realclean.
• Gestion simplifiée de la variable TEXINPUTS pour avoir facilement ses fichiers répartis dans plusieurs dossiers.
• Gestion des réglages d'impression PostScript définis grâce à texconfig

Il y a des indications plus détaillées sur le wiki: https://bitbucket.org/michipili/bsdowl/wiki/ProduceLaTeXDocuments (in inglishe) Peut-être que je vais en faire une version “dépêche” pour LinuxFR lorsque j'aurais packagé ça dans Debian.

BitBucket existe encore ? […] Ça fait plus envie que github.

GitHub est bien plus vivant et à la mode que BitBucket. Donc plutôt “non” pour ta première question!

Pourtant l'UX de GitHub est complètement insupportable en soi et bien moins bonne que celle de BitBucket si on fait des comparaisons.

Mais le projet est aussi sous GitHub, pour ceux qui veulent! :)

https://github.com/michipili/bsdowl