🚲 Tanguy Ortolo a écrit 12091 commentaires

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.

Il est à noter que la censure d'État sur Internet existe déjà en France, sur décision judiciaire il me semble, pour des motifs tels que l'organisation de jeux d'argents non autorisés. Cette censure est mise en œuvre par les grand opérateurs d'accès à Internet, sous la forme de mensonges dans les réponses de leurs services de résolution de nom de domaine.

Merci, mais rien de tout cela n'indique pourquoi systemd est nécessaire, ni même en quoi il faciliterait quoi que ce soit. Pourquoi un simple startx en utilisateur ne pourrait pas lancer X sans setuid root ?

Debian propose toujours SysV, même dans la testing : ce n'y est plus l'init par défaut, mais il est toujours là.

Donc il existe du bon dans le secret industriel comme dans les brevets.

Si tu fais référence à la chartreuse, le secret, qui permet que seuls les pères chartreux en produisent, n'a rien de bon pour le consommateur. Si la recette été connue, il y aurait des tas de concurrents proposant des liqueurs tout à fait identiques et donc substituables, pour un prix inférieur. Ce serait en revanche certainement difficile pour les pères chartreux.

On est d'accord. Personnellement, je trouve que vu les abus actuels, le système de brevet ne contribue plus à son but initial qui est de favoriser l'innovation. En revanche, je ne pense pas qu'il soit judicieux de l'abolir, pas dans tous les domaines en tout cas. Il serait à mon avis plus utile de le réformer, en imposant des contraintes telles que :

• rémunération de l'office des brevets indépendante du volume de brevets accordés ;
• pas de prototype qui fonctionne ⇒ brevet invalide ;
• homme de l'art incapable de reproduire un prototype qui fonctionne à partir du brevet ⇒ brevet invalide ;
• brevet invalide pour ce genre de raison ⇒ amende dissuasive pour l'auteur et pénalité pour l'employé de l'office de brevet qui l'a accordé quand on le découvre, par exemple à l'occasion d'un procès ;
• brevet inutilisé pendant N d'années ⇒ brevet automatiquement invalidé, avec publication régulière d'une liste de ces brevets invalidés.

Je pense notamment à un brevet récent d'IBM sur un système de protection contre les tirs d'arme à feu par film du projectile, analyse de sa trajectoire et stimulation neurale de l'utilisateur pour lui faire éviter la balle façon Matrix : ce truc n'est pas réalisable aujourd'hui, donc leur prototype n'existe pas et leur description de ce système est bidonnée ; ce genre de pratique mériterait une amende pour IBM et une pénalité sur le salaire de l'employé qui a validé cette connerie. Voire un licenciement pour faute, parce que son boulot est d'analyser les demandes de brevets, ce qu'il n'a pas fait dans ce cas.

Le système de brevets a des inconvénients, de plus en plus significatifs au fur et à mesure qu'on en abuse, mais il ne faut pas oublier son but initial, enfin, ce qu'on m'a appris comme tel : inciter les inventeurs à publier leurs inventions plutôt que de recourir au secret industriel.

En effet, sans système de brevet, un inventeur cachera spontanément ses inventions, pour éviter qu'on les copie et en tirer ainsi un avantage concurrentiel. Or, l'innovation nécessite une grande part de copie, d'inspiration et d'amélioration sur l'existant, le secret industriel étant ainsi nuisible à l'innovation. Le système de brevet fournir ainsi un avantage concurrentiel artificiel, sous le forme d'un monopole temporaire garanti par contrainte légale, avec pour contrepartie l'obligation pour en bénéficier de publier son invention, permettant ainsi à quiconque de l'imiter — pas pour la vendre telle quelle, ça c'est interdit — pour l'améliorer ou s'en inspirer de façon générale.

Je ne vois pas le rapport avec systemd.

Pas de problème. Je ne trouve pas ma syntaxe si difficile à lire à partir du moment où 1. on n'a pas de coloration déconnante, et 2. on considère bien que toute la commande à substituer entre les parenthèse est interprétée à part. Au contraire, je trouve ça plus lisible qu'avec des échappements, dont j'ai d'ailleurs peur qu'ils ne fonctionnent pas du tout (le shell verra une commande avec des \", c'est quoi ça ?).

Et pour ce qui est d'encadrer de guillemets inutilement, je pars du principe que l'utilisateur, ou celui qui modifiera mon script, pourra mettre les pires conneries dans mes variables, donc je blinde. Une bonne habitude à prendre d'ailleurs, consiste à forcer l'arrêt des options avant de donner un argument variable à une commande histoire de se prémunir des variables commençant par un tiret, genre :

ln -s -- "$file" "$target"