🚲 Tanguy Ortolo a écrit 12336 commentaires

Merci capitaine évident. Et à part ça, j'ai le droit de critiquer, ou seulement de fermer ma bouche ?

Parce que c'est un grand pas dans le verrouillage des utilisateurs, avec une mise en œuvre d'informatique déloyale que même Microsoft avait renoncé à faire. Le monde se porterait mieux si Apple n'existait pas, ou s'ils existaient mais ne verrouillaient pas leurs appareils et les logiciels qui tournent dessus.

Dit donc les prix ont vachement baissé ! Par contre, niveau distribution c'est très limité… C'est soit du Debian 7 ou du Ubuntu, et ArchLinux alors ?!

Sur du dédié, tu peux installer ce que tu veux, à condition de disposer d'une procédure d'installation qui ne nécessite pas d'accès physique ni d'accès déporté à l'écran et au clavier.

Pas convaincu : Apple ont souvent sorti des appareils qui n'avaient rien de nouveau, et qui étaient apparemment très décevants. Par exemple, l'iPad : un ordinateur sans clavier, sans souris, sans lecteur de carte mémoire, sans port USB, avec un écran tactile (ce qui existait déjà)… Sauf que malheureusement, ça a fait un carton !

Les fichiers requis ont (à peu près) tous une raison valable d'exister : le control c'est celui qui correspond le mieux à ce qui existe dans les autres distros pour « définir » le paquet ; le copyright est séparé car historiquement non-structuré, contrairement au control, même si ça n'est plus le cas aujourd'hui

Même structuré, je suis content que le debian/copyright soit séparé du debian/control, parce que c'est souvent p****n de long, ce qu'on met dedans. Pensez donc, des licences entières, et parfois plusieurs, si c'était dans le debian/control ça n'améliorerait pas sa lisibilité !

Ah ben non, la demande est différente. Aider un nouveau mainteneur de paquet, ça je peux faire, j'ai déjà fait d'ailleurs.

Et pour répondre à la question, non, je n'ai pas essayé autre chose, faute de raison de le faire !

Mais attention, l'option -L ca ne fonctionne que pour un paquet deja installé. Pour lister les fichiers fournis par un paquet à partir du fichier .deb non installé, c'est dpkg-deb qu'il faut utiliser. Et l'option n'est pas la meme evidemment, la c'est l'option -c de dpkg-deb qu'il faut utiliser pour lister les fichiers.

Là, c'est chercher la petite bête : tu devrais pouvoir reconnaître qu'entre lister les fichiers qui ont été fournis par un paquet installé, et ceux d'un paquet présent dans l'archive d'un paquet non installé mais présent dans le répertoire courant, ce n'est pas du tout le même boulot. Dans le premier cas, cela consiste à interroger une base de données locale, l'archive du paquet n'étant probablement nulle part sur ton ordinateur. Dans le second cas, cela consiste à lister le contenu d'une archive.

dpkg-deb sert à analyser des archives de paquets oui. Mais ça sert très peu pour un utilisateur normal, parce qu'il n'est justement pas habituel de télécharger à la main un paquet seul.

rajoute que ce répertoire doit obligatoirement se trouver à la racine lors de la "compilation"

Oui, ça s'appelle une convention plutôt qu'une configuration. Les outils de construction de paquet vont chercher un répertoire ./debian, pas ../debian ou /quelque/part/debian. Si c'est problématique, il y a sans doute des solutions : si c'est lié à l'imbrication de systèmes de versionnement par exemple, il y a des trucs comme svn-buildpackage qui permettent d'éviter cela.

La commande pour installer ou chercher n’est pas là même (apt-get vs apt-cache),

Tu vas être content, avec la prochaine Debian il y a une commande de haut niveau, apt tout court : apt search, apt show, apt install, apt update, apt upgrade…).

et des opérations qui sont de base et super simples sous Arch sont impossibles sans outil externe : savoir à quel paquet appartient un fichier, lister les fichier d’un paquet

Là il y a une séparation sous Debian et ça complique en effet : c'est liée au fait qu'APT est une sur-couche au système d'installation des paquets qui est dpkg. Pour faire simple, dpkg installe des paquets et gère les fichiers des paquets installés, alors qu'APT est un ensemble d'outils (en fait une bibliothèque et des outils qui l'utilisent) pour télécharger des paquets et leur dépendances.

Donc, pour les fichiers des paquets, c'est dpkg. dpkg -S pour chercher quel paquet a installé tel fichier, et dpkg -L pour lister les fichiers installés par un paquet.

Ah, ça. Question de goût, entre tout mettre dans un fichier avec des tas de sections ou mettre un fichier par tâche. Entre un fichier contenant des sections ou un répertoire contenant des fichiers, c'est un peu kif-kif à mon avis, quoique, vu que certains fichiers (debian/control: description du paquet source et des paquets binaires générés, et debian/copyright: description des licences utilisées dans le logiciel et le paquet) utilisent déjà des sections ce n'est pas plus mal d'avoir des fichiers séparés.

Même chose pour la configuration d'un logiciel d'ailleurs, enfin pour pas mal de trucs qu'on trouve dans /etc quoi, il y a plusieurs approches, avec es avantages et des inconvénients pour les humains et pour les logiciels chargés de lire ou de modifier ces données.

C'est une proposition fantastique et très sympa! J'ai préparé une branche debian avec mon travail préliminaire:

Je l'utiliserai sans doute, en revanche après ce sera ma branche debian évidemment. Il ne sera pas forcément utile de la conserver dans ton dépôt, puisque j'aurai le mien.

Si j'ai bien compris le workflow typique consiste à garder cette branche à part et à y merger régulièrement master à chaque nouvelle version.

Il existe plusieurs pratiques d'empaquetage sous Git, mais c'est la mienne et je ne suis pas le seul à l'utiliser. :-)

C'est moi qui m'occuperai de cela ; il serait utile d'avoir un tag Git pour chaque nouvelle version, et que les fichiers y correspondent autant que possible au contenu du tarball officiel correspondant. Si ce n'est pas le cas, c'est à dire s'il y a de grosses différences entre le contenu du dépôt Git et le contenu des tarballs publiés, je ferai moi-même une branche tarball pour mon usage (ça arrive)…

Bon, je te tiendrai au courant. Ça m'intéresse ce projet, parce que compiler du LaTeX avec un Make, c'est quelque chose que j'aime bien. Et les taballs sont signés en plus ! La classe (ça peut être vérifié automatiquement par un paquet Debian source, mais je n'avais jamais eu l'occasion d'utiliser cette fonctionnalité) !

Et ça aurait été tellement compliqué voire impossibe que uscan ouvre le fichier "central" et lise la ligne qui va bien…

Quel fichier « central » ? Tu veux dire, indiquer à uscan une URL où il pourra toujours trouver la dernière version, puis qu'il l'extraie et aille lire un fichier qui indique le numéro de version ? Cela suppose deux choses :

• qu'il existe une URL unique vers un upstream-latest.tar.gz, ce qui n'est pas toujours le cas ;
• que le tarball amont contienne un fichier indiquant le numéro de version, ce qui n'est pas non plus toujours le cas.

un .spec (rpm), dans ce que je connais, permet la même chose, et donc?

Donc rien, c'est une fonctionnalité présente dans RPM, très bien. C'est le genre de truc que je m'attends à voir dans les outils d'empaquetage bien fournis, mais pas dans des trucs volontairement très simples, c'est tout.

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…).