Re: Point par point

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 graveTM 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!