🚲 Tanguy Ortolo a écrit 12224 commentaires

Vous connaissez des usages du tactile sous linux?

Je crois que c'est massivement utilisé sous Android. Bon, c'est une distribution très particulière, mais il doit en exister d'autres pour ce genre d'usage, genre Meego, ou quel que soit le nom que ce projet peut porter maintenant.

Ah non excusez-moi, on parle de mainteneurs qui ont patché des logiciels à l'insu des développeurs. Il faut forcément avoir un changelog spécifique aux bidouilles Debian.

Il y a deux types de patchs. Ceux qui corrigent des bugs amont, ou apportent des fonctionnalités, et qui doivent alors être remontés au projet amont, où ils peuvent être acceptés, refusés ou ignorés. Et il y a les patchs spécifiques à Debian, par exemple pour qu'on logiciel colle à la FHS, ou se conforme aux règles de Debian permettant de mettre en œuvre le multiarch, ou encore utilise des bibliothèques fournies par Debian au lieu de celles qu'il embarque normalement. Ces patchs-là n'ont aucune raison d'être envoyés au projet amont, où ils n'ont rien à faire.

Gné ? Que le serveur dise "j'ai la version 1.2.23" et que le client comprenne "tiens, j'ai la 1.2.21 sur mon ordi, il y a donc une nouvelle version" quand le client met à jour la liste des paquets des dépôts, ça nécessite de complexifier la procédure de création de paquet ?

Ben ça nécessite un fichier où écrire des choses comme (dans un cas simple) :

• où se trouve l'index des version du logiciel ;
• dans les noms des tarballs amont, où se trouve le numéro de version.

Cela doit aussi permettre de gérer des cas compliqués, avec par exemple des numéros de version amont qui doivent être transformés (par exemple parce qu'un jour, la numérotation amont a été modifiée de façon incompatible, et qu'heureusement Debian prévoit ce genre de cas avec un préfixe spécifique, qu'il faut alors ajouter), ou encore des archives à refaire à la volée pour en exclure quelques fichiers non libres.

Pour info, le fichier en question c'est debian/watch, utilisé par l'outil uscan (upstream scan).

la définition éventuelle des fichiers à mettre dans tel ou tel paquet binaire dans le cas d'une séparation en plusieurs paquets.
Là, je suis curieux d'avoir des cas pratiques.

Simple : OpenDKIM. C'est une mise en œuvre de la norme DKIM de signature de courrier életronique par les serveurs. Ce projet fournit deux choses, qui devraient pouvoir s'utiliser de façon indépendante :

• un milter, c'est à dire un démon auquel un serveur de courrier va déléguer la tâche de signature ou de vérification des messages ;
• des outils de génération de clefs et de test.

Ça tombe bien, dans Debian ils ont été séparés en deux paquets.

Autre cas d'usage, GRUB 2. Sous Debian, il a été séparé en plusieurs paquets, de sorte qu'on peut installer par exemple les bibliothèques et outils de GRUB pour PC et pour EFI amd64 (dans le but de réaliser des clefs USB démarrables pour ces deux plate-formes), et installer localement seulement GRUB pour PC comme chargeur de démarrage.

Enfin, c'est très utile pour la mise en œuvre d'installations simultanées de logiciels pour plusieurs architectures, mais c'est un vaste sujet.

Le Portfile précise la license utilisée

license             CeCILL-B

La licence ? Et quand il y en a plusieurs ? Quand il y a un fichier qui est sous une licence distincte ? Quand l'empaqueteur ne peut pas licencier son travail de la même façon (projet amont dans le domaine public et empaqueteur en France par exemple) ?

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:
[…]
Est-ce que ça suffit?

À condition d'aimer Subversion, oui. Je suis pour ma part heureux que Debian n'impose pas d'utiliser ce système que j'aime de moins en moins.

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.

En effet, ça s'adresse aux mainteneurs Debian qui ne sont pas également développeurs amont, ces derniers étant forcément les premiers au courant de leurs nouvelles versions. Mais pas seulement : c'est également utilisé par des outils automatiques de la plate-forme de qualité de Debian, pour réaliser des rapports agrégés, par exemple sur tous les paquets dont s'occupe Untel, en indiquant notamment lesquels sont en retard sur la version amont.

Ça permet en une commande de vérifier s'il y a une nouvelle version amont, de la télécharger et de la renommer pour qu'elle colle à la nomenclature Debian. Et ça permet également, au besoin, de la ré-empaqueter, par exemple si elle est fournie au format ZIP (il faut un tarball) ou si elle contient des fichiers non libres (qu'il faut alors retirer).

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é

Oui, c'est compliqué, et inutile dans les cas simples. Mais cela permet par exemple de séparer le milter OpenDKIM des outils OpenDKIM, permettant ainsi aux utilisateurs d'installer de quoi générer des clefs DKIM sans avoir à installer le serveur de signature et d'analyse de messages.

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.

Le système d'empaquetage de Debian est complexe, il n'y a rien à dire à ce sujet. Mais les tâches sont plutôt bien séparées, et en commençant avec un paquet pas trop compliqué (genre pas un démon qui nécessite de la configuration de la part de l'utilisateur), je ne pense pas qu'il soit trop difficile de débuter, à condition de s'intéresser sérieusement à Debian (l'empaquetage Debian par un développeur amont qui n'utilise pas Debian ou seulement de façon occasionnelle, on peut oublier, c'est clair), et cela se retient plutôt bien. La documentation est un problème, d'où la récente page du wiki Debian je crois. Et sinon, il ne faut pas hésiter à demander sur le salon IRC qui va bien (#debian-mentors sur OFTC).

a une époque apt-get et aptitude ne géraient (par défaut) pas de la même façon les dépendances recommended de sorte que si tu installait un paquet avec l'un et désinstallait avec l'autre tu pouvais avoir des paquets qui restent

En effat, mais comme c'est sans autre conséquence qu'une occupation d'espace, ce n'était pas vraiment une problème sérieux.

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

Eh bien, si tu préfères te consacrer à autre chose, je peux peut-être le faire, l'empaquetage Debian, si tu veux. C'est sûr que l'empaquetage Debian est presque une vocation à part, et comme je sais déjà faire, ça me prendra beaucoup moins de temps. Et en plus, ton logiciel est sous Git, ce que j'apprécie.

faut utiliser aptitude toujours et tout le temps

Ça, ça n'a jamais été vrai. Jamais.

non faut utiliser apt-get, aptitude est deprecated

C'est simple : à une époque, aptitude a été recommandé pour passer d'une version Debian à la suivante. Depuis, apt-get a été amélioré et suffit à cela ; comme il est plus léger il est à nouveau recommandé à la place, mais on peut toujours utiliser aptitude si on préfère, comme on pouvait à l'époque utiliser apt-get si on préfère.

faut prendre aptitude pour les distros upgrade et apt-get pour le reste

Aujourd'hui tu fais ce que tu veux. Les deux ont un solveur de dépendances différent, celui d'apt-get étant normalement suffisant mais celui d'aptitude étant plus puissant et donc parfois préférable pour des situations complexes. Personnellement j'utilise normalement apt-get, et aptitude lorsqu'apt-get ne donne pas de solution convenable pour les cas où je suis en partie en Debian stable, testing et unstable.

apt-get te cassera ta distrib!

Jamais, en tout cas jamais sans te demander une confirmation très précise (par un « o/n », mais une vraie confirmation impossible à valider par erreur, genre : recopie exactement la phrase « oui, je veux vraiment faire ça »). apt-get peut, dans des situations complexes, proposer une solution qui implique de retirer pas mal de truc, mais ça demande toujours une confirmation.

Effectivement, c'est simple, il n'y a rien à dire. Maintenant, je soupçonne que cela permette moins choses en contrepartie, comme l'indication formelle des licences utilisées, l'ajout de patchs spécifiques annotés, 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 notifications automatiques de la présence d'une nouvelle version amont avec automatisation du téléchargement et de leur intégration dans ton empaquetage, la définition éventuelle des fichiers à mettre dans tel ou tel paquet binaire dans le cas d'une séparation en plusieurs paquets. 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.

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.

Je n'ai rien compris à ce que tu veux faire là. Tu as une nouvelle version amont qui résoud un bug numéroté XXXXX dans le BTS Debian ?

On crée une branche debian dans laquelle on merge master à chaque nouvelle version?

Personnellement, j'ai une branche master qui correspond au développement du paquet Debian, et lorsqu'il y a une nouvelle version amont, je fusionne upstream/master dans ma branche master oui. C'est assez logique je trouve : j'importe les changements amont, le paquet Debian source n'étant en somme qu'une modification par-dessus les sources amont.

Du côté de debian, c'est beaucoup moins clair,

Ah ben, tout le boulot d'empaquetage dans le répertoire debian/, c'est relativemant clair tout de même. Et si tu tiens à le mettre à part, il y a des outils pour ça, genre svn-buildpackage (que je n'aime pas du tout).

c'est à mon avis plus difficile de voir les différences avec l'upstream

Ben, si tu veux ce qui vient d'amont, c'est tout sauf debian/, ce n'est pas franchement compliqué. Tu peux faire des diff --exclude=debian/ par exemple.

alors qu'avec d'autres systèmes on dispose de sha-2 voire de signature gpg

D'autres système, genre… Debian par exemple ?

(Pour préciser, cet exemple est un paquet binaire, composé de deux fichiers : le tarball amont et une archive debian qui contient la partie spécifique à l'empaquetage. Leurs sommes SHA-1, SHA-256, et MD5 je crois, sont précisées, et la description du tout est signée avec PGP. Lorsqu'on extrait ce paquet source, le tarball amont est extrait, puis le tarball debian dans un répertoire debian/)

on peut directement construire le paquet binaire, et là c'est un répertoire DEBIAN qu'il faut

En effet, qui se retrouvera dans la sous-archive debian.tar.(quelque chose) du paquet binaire : ce répertoire DEBIAN/ n'est qu'une convention de l'outil qui fabrique les paquets binaires, et normalement une étape transitoire. Pour un paquet source « normal », c'est un répertoire debian/, qui n'a pas grand chose à voir.

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!

Perso si c'est aussi simple à compiler je peux le faire en une demi-heure. Mais autrement, c'est comme toujours : un coup de dh_make, éditer les fichiers ainsi créés dans debian/, et adapter le debian/rules pour utiliser bmake au lieu de make (en explicitant les cibles qui vont bien, là par cœur je ne saurais pas dire lesquelles).

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

Bof, un coup de dh_make, et tu édites le contenu de debian/ qui est auto-documenté.

Si tu ne veux pas versioner ton dossier DEBIAN

debian, en minuscules. Le répertoire DEBIAN, c'est dans les répertoires temporaires de construction des paquets binaires, et en pratique jamais visible, ni par l'empaqueteur, ni par l'utilisateur (enfin il me semble, c'est dire si c'est invisible…).

L'empaquetage pour Debian est à la distribution de logiciels ce que git est aux gestionnaire de version de code

Un outil génial donc. C'est bien mon avis aussi, merci.

Non mais sérieusement, commencer par ce genre de comparaison, à part pour troller, ça a quoi comme intérêt ? Les gens ont un avis différent sur différents logiciels, donc mieux vaut se prononcer avec un avis clair plutôt qu'avec une comparaison à d'autres logiciels qui n'ont rien à voir.

Pourquoi ? Soit, voyons ça point par point.

Dès le début c'est folklorique! D'abord il faut que je renomme la tarball. (Mais pourquoi? Peut-être pour éviter d'écrire le numéro de version dans le fichier de configuration?)

Pour qu'ils soient faciles à identifier dans l'archive Debian ? Les développeurs amont n'ayant pas de convention uniforme pour nommer leurs archives, Debian normalise cela. Personnellement je trouve cela agréable, ainsi en téléchargeant des paquets sources on se retrouve avec des noms cohérents dont chacun suffit à identifier : de quel paquet il s'agit, et de quelle version de ce paquet il s'agit. Laisser les noms des archives amont aurait des avantages et des inconvénients, mais renomment un fichier est si facile qu'il me semble spécieux d'arguer sur ce point précis.

Ensuite je dois exploser la tarball et travailler dans le dossier des sources, où je crée un dossier debian qui contient mon petit krims-krams de packageur. On voit tout de suite l'avantage de ce système:

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.

comme mon krims-krams est en RCS

Bon, je vais me forcer à continuer à lire malgré cet archaïsme ahurissant.

je dois faire un checkout à chaque fois que je fais une mise-à-jour du système, et si par hasard j'ai choisi git…

Si par hasard tu as choisi Git, c'est parfait. C'est ce que j'utilise, et ça marche très bien : si les développeurs amont utilisent aussi Git tu mets ton répertoires source (amont + répertoire debian/) dans une branche qui en dérive, et s'ils n'utilisent pas Git tu fais pareil sauf que c'est toi qui crées la branche amont à partir des tarballs qu'ils fournissent.

Du coup, la meuilleure stratégie est sûrement de symlinker le dossier debian vers le dossier adéquat de ma copie de travail contenant tous mes trucs de packageurs.

Probablmenet pas non. La meilleure stratégie est à mon avis de versionner le tout (sources amont + répertoire debian/), mais certains préfèrent effectivement ne versionner que leur travail d'empaquetage, ce qui nécessite d'utiliser des scripts spécifiques pour cela. Personnellement je n'aime pas du tout cela, à cause du côté artificiel lié à l'utilisation de ces scripts.

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.

Ensuite il faut que je crée un ChangeLog contenant le numéro de ticket où j'ai annoncé au monde entier que j'allais écrire un package.

Ça, ce n'est pas pour t'embêter mais pour te simplifier la vie : quand tu enverras ton paquet, ça ira automatiquement fermer le pseudo-bug correspondant à ton annonce d'empaquetage. Quant au fait d'avoir un changelog d'empaquetage, ça n'a rien d'anormal.

Bon, je le remplirai quand j'aurais fini, mais ça serait quand-même plus simple si mes fichiers de packagers soient sous RCS et que tout le monde puisse regarder le log de ces fichiers…

Encore RCS ? Bon, alors, déjà, que ce soit clair : le format de paquets de Debian est indépendant des systèmes de gestion de version, et heureusement, parce que sinon on risquerait d'être coincés avec des vieilleries comme justement RCS, ou de se voir imposer Mercurial alors qu'on préfère Git… 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.

Ensuite il faut que j'écrive un fichier rules qui est un GNU Makefile, un peu à la FreeBSD en somme. Sauf que là je dois le replir avec une incantation vaudoo un peu moins parlante que .include :

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). Si tu veux les écrire toi-même, en indiquant ce qu'il faut faire pour chaque étape, tu peux. Sinon tu peux utiliser la syntaxe que tu mentionne, 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. Et sinon, tu peux aussi utiliser CDBS, un système à base d'include comme tu as l'air d'aimer.

Après quelques hésitations on arrive enfin à un truc qui marche à peu près, mais on croit avoir tout bien fait et lintian nous crache une page d'insultes à la gueule — désolé j'ai recopié l'exemple du livre moi!

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.

Pourquoi est-ce que c'est aussi compliqué et aussi mal expliqué sous Debian, alors que c'est simple et clair ailleurs?

Compliqué, parce qu'on veut faire quelque chose de propre, solide et bien documenté, et que s'il suffisait pour cela de compiler le logiciel amont, ça se saurait. Debian existe pour uniformiser un système, et ça demande des efforts, sinon il n'y aurait pas de distribution.

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

Voilà un bel exemple de perversion totale du système de brevet, dont l'effet est exactement opposé à son objectif initial !

Concernant les réseaux sociaux, je ne suis pas bien placé pour te répondre. Mais pour ce qui est de se faire connaître des lecteurs, et subséquemment des moteurs de recherche, il y a les planètes d'agrégation de blogs. Planet Debian, Planet Debian-Fr, Planet Libre, Planet April si tu es adhérent (sinon adhère !), planète auto-hébergement si tu traites de ce sujet, &c.

Autre exemple, le format « orienté machine » d'indication de licence des différents fichiers qui compose un paquet Debian. D'une façon générale, c'est le cas de presque tous les formats descriptifs spécifiques à Debian utilisés dans les paquets d'ailleurs, je pense en particulier au format d'annotation des patchs. En fait, tous ces formats sont eux-mêmes basés sur un format conçu pour être lisible aussi bien par un humain que par une machine : le courrier électronique, enfin son en-tête évidemment.

J'avais eu un « cours » (en fait, de la propagande le l'INPI) sur les brevets par mon école doctorale. Pour de la recherche académique, on peut librement exploiter les brevets.

Pour tout ce que tu veux en fait, exception faite d'une exploitation commerciale. N'importe qui peut reprendre un brevet et construire la machine qu'il décrit dans son garage, pour son usage personnel.

Accessoirement, la formulation à laquelle tu réponds est fausse à la base : un outil ne promeut rien du tout, un outil est utilisé pour promouvoir…

Après, certains outils peuvent être intrinsèquement orientés d'une façon qui favorise une utilisation néfaste, mais c'est un autre sujet.

Et dans la cuisine aussi. Mets les composés chimiques constituant une tarte au citron meringuée en bonnes quantités dans un plat, et ça ne te fera pas une tarte au citron. Il manque l'organisation physique là.

Si tu comptais sur cela pour prouver l'existence d'une âme, désolé mais ce n'est pas suffisant (personnellement, j'y crois, mais là ce n'est pas une preuve).

Maintenant je la dilue dans l'océan, il se passe quoi ?

Rien, parce que tu ne l'as pas « dynamisé » en le secouant à chaque dilution pour conserver l'effet.

(Sinon, prononcer la bonne formule pourrait aussi marcher, si ça se trouve, au lieu de secouer…)

Ah non. En rassemblant les substances chimiques précises dans les mêmes quantités, tu obtiendrais une copie parfaite, et tout à fait hors de prix.

Dans ce cas, la recette originale, qui utilise des plantes et un procédé précis, est plus efficace et beaucoup moins coûteuse que la reconstitution chimique à partir de substances pures.

Certes. Mais que feras-tu du résultat, qui indiquera simplement que la chartreuse est constituée de tant de parties par million de tas de substances chimiques aromatiques pures ? Acheter ces substances pures pour composer une chartreuse reconstituer hors de prix ? Ce serait intéressant pour la curiosité, mais cela n'aurait aucun intérêt commercial…

Ben non, le secret aurait le même effet pour une méthode industrielle par exemple : procurer un avantage concurrentiel à celui qui le détient.

Ceci étant, il me semble que le secret est utilisé dans l'agro-alimentaire parce qu'une recette n'est pas éligible aux brevets. Un procédé, peut-être, mais une recette, j'en doute.