Journal Pourquoi écrire un package Debian est-il si compliqué?

Posté par Michaël (site web personnel) le 08 septembre 2014 à 16:11. Licence CC By‑SA.

Étiquettes :

sept.

2014

Bonjour Nal,

j'ai commencé à écrire des Packages pour Debian et je ne comprends pas pourquoi il faut que cela soit si compliqué.

Cela fait depuis plus de dix ans que j'écris des ports pour FreeBSD et cinq ans pour MacPorts. Je suis donc habitué à ce genre d'instructions:

Quick Porting pour FreeBSD, qui traite le cas facile en 3 pages A4.
Portfile development pour MacPorts qui traite le cas facile aussi rapidement — et la documentation est encore plus claire que celle de FreeBSD.

Pour les deux systèmes, le cas facile demande d'écrire un fichier où j'écris 5-6 paramètres comme la license et le nom de la tarball et puis zou. À la fin du processus, j'ai un fichier que je peux uploader pour l'intégrer à la collection de ports. C'est indolore et rapide, le pied quoi!

Maintenant je regarde ce que doit faire le packager chez Debian. Je commence donc par le guide rapide pour les gens pressés.

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?) Souate, renommons la tarball. 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: comme mon krims-krams est en RCS, je dois faire un checkout à chaque fois que je fais une mise-à-jour du système, et si par hasard j'ai choisi git… hm pas top. 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.

Ensuite je dois écrire un 9 dans le dossier debian/compat. Qui ne contient que cette seule donnée. 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. 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… Tu me diras, en cas d'hiver nucléaire, je serais bien content de les avoir ces ChangeLogs sans avoir besoin de me connecter online.

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 <bsd.ports.mk>:

#!/usr/bin/make -f
%:
        dh $@

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!

La suite logique est de passer par le New Maintainer's Guide exemple typique de documentation complètememt imbitable:

Pas de sommaire simple des étapes du processus.
En plein milieu il y a un chapitre (5) consacré aux différents fichiers qui peuvent vivre dans le doissier debian mais pas trop d'information générale.
Apparemement il y a au moins trois commandes différentes pour compiler le package et sept commandes pour chercher les erreurs dans le package.

Et je vous épargne encore le plaisir d'écrire un fichier copyright!

Suis-je le seul à trouver le processus complètement byzantin? Franchement je ne connaus rien à tcl, le langage dans lequel est écrit le Portfile utilisé par MacPorts, et j'ai déjà écrit une dizaine de Portfiles — à chaque fois j'oublie toute la prcédure, mais comme la doc est nickel, ça ne me prend pas plus d'une heure ou deux. Avec FreeBSD je le fais rapidement aussi, mais là ce n'est pas du jeu pqarceque j'ai beaucoup plus d'expérience.

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

# Parce que Debian = "Pourquoi faire simple quand on peut faire compliqué"

Posté par totof2000 le 08 septembre 2014 à 16:40. Évalué à 10.

C'est une des raisons pour laquelle j'ai mis longtemps à m'intéresser à cette ditribution.
# c'est pour qui le paquet ?

Posté par kna le 08 septembre 2014 à 16:46. Évalué à 10.

Comparer des ports a des paquets précompilés est un peu biaisé comme comparaison, mais je pense que tu as tout de même raison : c'est compliqué de faire un paquet debian.

Du moins, c'est compliqué de faire intégrer un paquet dans debian. Parce que si tu veux juste faire un paquet pour toi, tu peux utiliser dpkg-deb : http://alp.developpez.com/tutoriels/debian/creer-paquet/
- [^] # Re: c'est pour qui le paquet ?
  
  Posté par Axioplase ıɥs∀ (site web personnel) le 09 septembre 2014 à 00:29. Évalué à 10.
  
  Quand tu crées tes ports, la fondation FreeBSD crée automatiquement les paquets binaires pour toi sur leur cluster "pointyhat" à partir de ton port.
  - [^] # Re: c'est pour qui le paquet ?
    
    Posté par Michaël (site web personnel) le 09 septembre 2014 à 12:36. Évalué à 7.
    
    Quand tu crées tes ports, la fondation FreeBSD crée automatiquement les paquets binaires pour toi sur leur cluster "pointyhat" à partir de ton port.
    
    Et si tu veux, tu peux aussi le faire à la maison avec poudriere — en trois commandes tu déploies une jail dédiée à la recompilation de packages.
  - [^] # Re: c'est pour qui le paquet ?
    
    Posté par Bapt (site web personnel) le 12 septembre 2014 à 19:46. Évalué à 4.
    
    C est pas la fondation du tout, mais le projet freebsd et plus particulierement portmgr.
    Pointyhat n avait rien d automatique ;) mais heureusement il est mort, maintenant oui c est automatique et c est poudriere qui est utilisé sous le capot
    - [^] # Re: c'est pour qui le paquet ?
      
      Posté par Axioplase ıɥs∀ (site web personnel) le 12 septembre 2014 à 20:48. Évalué à 2.
      
      Tant d'infos incorrectes. Ça m'apprendra à pas maintenir mes ports correctement :)
# C'est compliqué parce que les choses ne sont pas simples...

Posté par Snark le 08 septembre 2014 à 17:11. Évalué à 10.

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

Par exemple, le fichier changelog sert à savoir quel est la version du paquet et quels bogues il ferme. Le fichier rules permet de gérer la compilation du paquet, avec toutes les étapes typiques d'une construction de paquet debian. Forcément, un simple port qui fait configure-make-make install est plus facile qu'un truc plus abouti qui va mettre la doc dans un paquet binaire, les libs dans un autre, les accessoires dans un autre, les données dans un autre, les fichiers de développement encore dans un autre.

Bref, il y a des raisons pas forcément évidentes au premier abord, on peut vouloir simplifier (dh sert à ça, d'ailleurs…), mais on ne peut pas non plus tout trivialiser.
- [^] # Re: C'est compliqué parce que les choses ne sont pas simples...
  
  Posté par Spyhawk le 08 septembre 2014 à 19:04. Évalué à 10. Dernière modification le 08 septembre 2014 à 19:05.
  
  Forcément, un simple port qui fait configure-make-make install est plus facile qu'un truc plus abouti qui va mettre la doc dans un paquet binaire, les libs dans un autre, les accessoires dans un autre, les données dans un autre, les fichiers de développement encore dans un autre.
  
  Certes, mais ça n'excuse pas tout. Faire l'équivalent en RPM est bien plus simple (et je ne parle même pas des PKGBUILDs). Moi j'ai plutôt l'impression que le packaging Debian est compliqué parce que c'était l'un des premiers venu, qu'il a évolué de façon organique un peu dans tous les sens au fil des années et que grâce à la bureaucratie made-in-Debian personne n'a jamais réussi à mettre tout ce schmilblick à plat pour repartir sur des bases plus saines et plus simples.
- [^] # Re: C'est compliqué parce que les choses ne sont pas simples...
  
  Posté par Michaël (site web personnel) le 08 septembre 2014 à 20:06. Évalué à 10.
  
  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.
  - [^] # Re: C'est compliqué parce que les choses ne sont pas simples...
    
    Posté par Snark le 08 septembre 2014 à 21:50. Évalué à 4.
    
    Alors déjà, comme mentionné par d'autres plus bas, en général le dossier debian/ est géré par un SCM. Tous mes paquets sont dans git! [Je ne suis pas DD et pas encore DM… je regarderai quand j'aurai fini avec la rentrée]
    
    J'insiste encore pour noter que le cas facile où le port fait un "make install" comme un porc (jeu de mots, pas taper) n'est pas si facile quand on fait un paquet correct : il faut assez souvent scinder le paquet en plusieurs morceaux (exemple: une lib ça mène souvent à trois paquets ; un pour la lib, un pour les fichiers de développement et un pour la doc…).
    
    Bref, on ne trouve ça facile que si on refuse de voir que c'est compliqué!
  - [^] # Re: C'est compliqué parce que les choses ne sont pas simples...
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 08 septembre 2014 à 22:44. Évalué à 5.
    
    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é.
    - [^] # Re: C'est compliqué parce que les choses ne sont pas simples...
      
      Posté par Axel le 08 septembre 2014 à 23:17. Évalué à 10.
      
      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.
      Non pas que tu sois un marathonien du packaging debian, j'en sais rien, mais c'est comme dire à un kenyan que c'est dur et long de courir un marathon parce que tu n'as pas réussi à trouver de méthode d'entrainement efficace, il te répondre "bof, en 2h c'est plié".
      - [^] # Re: C'est compliqué parce que les choses ne sont pas simples...
        
        Posté par Michaël (site web personnel) le 08 septembre 2014 à 23:43. Évalué à 9.
        
        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.
# Point par point

Posté par 🚲 Tanguy Ortolo (site web personnel) le 08 septembre 2014 à 17:14. Évalué à 10.

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.
- [^] # Re: Point par point
  
  Posté par gnumdk (site web personnel) le 08 septembre 2014 à 17:55. Évalué à 10.
  
  Reste quand même le problème des multiples commandes pour builder le paquet, des mutiples outils pour faire un paquet (dh, cdbs), c'est vraiment pas le truc le plus clair du monde…
  - [^] # Re: Point par point
    
    Posté par Nitchevo (site web personnel) le 08 septembre 2014 à 19:15. Évalué à 9.
    
    Bonjour,
    
    La lecture du journal m'a rappelé les difficultés que j'avais rencontrées en installant ma première Debian (Woody!). C'était tellement compliqué que tu avais l'impression d'être idiot à chaque pas de l'installation. Je pensais que l'utilisation comme serveur allait être une vraie horreur, mais non ça marchait parfaitement, c'était clair, que du bonheur. Bref Debian, pour moi, c'est un système d'un abord difficile dont tu mets du temps à comprendre la logique, mais qui marche.
  - [^] # Re: Point par point
    
    Posté par Michaël (site web personnel) le 08 septembre 2014 à 21:44. Évalué à -2.
    
    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!
    - [^] # Re: Point par point
      
      Posté par barmic le 09 septembre 2014 à 00:06. Évalué à 10.
      
      Ouai enfin personne n'utilise dselect depuis très longtemps, apt-get/aptitude/synaptics/apt (le petit nouveau qui arrive avec la prochaine debian) c'est du pareil au même. 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. Non, tu fais comme tu le veux quand tu le veux. J'insiste c'est exactement comme éditer un fichier tu peux installer un paquet avec l'un et désinstaller avec l'autre, les légers problèmes d'incompatibilités sont de l'histoire ancienne depuis pas mal de temps. Le projet Debian en préconise un parce qu'il faut en choisir un, mais dans les faits tu fais ce que tu veux.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Point par point
        
        Posté par Michaël (site web personnel) le 09 septembre 2014 à 00:30. Évalué à 2.
        
        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!)
      - [^] # Re: Point par point
        
        Posté par octane le 09 septembre 2014 à 09:25. Évalué à 10.
        
        Le projet Debian en préconise un parce qu'il faut en choisir un, mais dans les faits tu fais ce que tu veux.
        
        On a quand même eu un grand moment entre aptitude et apt-get ou à peu près toutes les docs se contredisaient:
        
        faut utiliser aptitude toujours et tout le temps
        
        non faut utiliser apt-get, aptitude est deprecated
        
        faut prendre aptitude pour les distros upgrade et apt-get pour le reste
        
        non c'est l'inverse
        
        apt-get te cassera ta distrib!
        
        aptitude est deprecated
        
        etc..
        
        Et d'ailleurs, j'ai jamais vraiment compris les tenants et aboutissants de ce chaos. Quoi qu'il en soit, apt-get fonctionne aujourd'hui. Et ça, je crois que mis à part deux ou trois debianistes fous furieux, personne n'a vraiment compris les raisons de ce truc. Et ça, il en reste des blogs entier conseillant l'un ou l'autre ce qui n'aide pas vraiment à la simplicité de la chose.
        
        [^] # Re: Point par point
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 09:32. Évalué à 4.
        
        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.
        
        [^] # Re: Point par point
        
        Posté par Sufflope (site web personnel) le 09 septembre 2014 à 20:23. Évalué à 10.
        
        faut utiliser aptitude toujours et tout le temps
        
        Ça, ça n'a jamais été vrai. Jamais.
        
        Euh si, plus ou moins. Je me souviens d'une doc sur le site debian qui disait qu'apt-get était deprecated et qu'il fallait utiliser aptitude qui était la nouvelle façon de gérer les paquets.
        
        Et non je ne la chercherai pas, parce que le site debian a été totalement refait, et parce que maintenant je m'en cogne de debian.
        
        [^] # Re: Point par point
        
        Posté par barmic le 09 septembre 2014 à 09:59. Évalué à 6.
        
        On a quand même eu un grand moment entre aptitude et apt-get ou à peu près toutes les docs se contredisaient:
        
        Et ? Comme à une époque la communication n'était pas génial, ça restera pourri à jamais ?
        
        Et ça, je crois que mis à part deux ou trois debianistes fous furieux […]
        
        Il y a eu 2 choses, si je ne me trompe pas :
        
        aptitude était meilleur à un moment pour gérer des cas complexes de dépendance
        
        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
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Point par point
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 10:10. Évalué à 0.
        
        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.
        
        [^] # Re: Point par point
        
        Posté par Sufflope (site web personnel) le 09 septembre 2014 à 20:25. Évalué à 10.
        
        Ouais bah les recommends qui de fil en aiguille te tirent un serveur mail (démarré automatiquement en plus, merci debian…) quand tu veux installer un truc à la con, tu pourrais t'abstenir de dire que c'est qu'un problème de place…
        
        [^] # Re: Point par point
        
        Posté par Chris K. le 10 septembre 2014 à 15:04. Évalué à 1.
        
        Euh les recommends sous debian ne tirent rien du tout automatiquement.
        Tu parles d'exim4 ? Si le paquet en question est susceptible d'envoyer des emails et qu'il dépend donc de la présence d'un MTA ou encore de la commande sendmail c'est tout à fait logique.
        Exim est configuré par défaut en relais local et pour écouter sur localhost : rien de très sensible et il a été choisi notamment car il est plutôt léger.
        A part sur une machine avec des ressources très limités (embarqué ?) ça ne doit pas poser de problème comme le dit Tanguy.
        Sinon il est possible de supprimer automatiquement les paquets installés comme dépendance d'un autre qui n'est plus présent sur le système, à l'aide de apt-get autoremove, qui fonctionne très bien depuis un bon moment maintenant.
        
        [^] # Re: Point par point
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 11 septembre 2014 à 10:55. Évalué à 3.
        
        Et surtout, ça se règle, de prendre automatiquement les simples recommandations ou seulement les dépendances dures.
        
        [^] # Re: Point par point
        
        Posté par Chris K. le 11 septembre 2014 à 13:30. Évalué à 1. Dernière modification le 11 septembre 2014 à 13:33.
        
        Effectivement pour ce qui est de la prise automatique j'ai confondu recommended avec suggested.
        Mea maxima culpa ^^.
        Par contre enlever les paquets recommandés peut casser des fonctionnalités du paquet, le cas du MTA est un bon exemple : il faut donc savoir exactement où l'on met les pieds et surtout avoir de la mémoire si le besoin d'activer ladite fonctionnalité se présente 6 mois plus tard.
        Il est aussi possible de passer l'option au cas par cas en cas de besoin, lors de l'appel d'apt avec --no-install-recommends.
        
        [^] # Re: Point par point
        
        Posté par freem le 11 septembre 2014 à 11:56. Évalué à 6.
        
        Je suis d'accord avec toi sur un point, pour le coup: le fait d'installer par défaut automatiquement les recommended, je trouve ça à chier. Parce que, ok, l'espace disque c'est pas cher, mais bon, installer les recommended ce n'est pas juste de l'espace disque: ce sont également des programmes qui sont chargés quand on utilise celui qui les à installés. Ils ne seraient pas recommandés s'ils n'étaient pas utilisés, après tout.
        
        Maintenant, ça se désactive (il s'agit de l'une de mes premières actions d'ailleurs), et puis, tous les utilisateurs ne savent pas forcément de quoi ils ont besoin, et installer automatiquement les recommended permets, j'imagine, d'éviter que les gens disent que ça ne marche pas out-of-the-box… même si pour moi Debian ne devrait pas cibler ce type de public (qui ne fait pas attention à ce qu'il installe ni aux "conseils" du système).
        
        Par contre, pour ce qui est de démarrer automatiquement les daemons lors d'une install, je trouve ça plutôt logique (et d'ailleurs, il existe des exceptions à cette règle) puisque quand on installe un daemon, en règle générale, c'est qu'il sera utile la plupart du temps. Pourquoi contraindre l'utilisateur (qui n'est pas nécessairement root en plus) à démarrer manuellement un service style dbus, cups, sshd?
        Et si tu as installé un serveur ftp, http ou samba (entres autres), c'est probablement que ta machine devra fournir un service à n'importe quel moment, non?
        Et puis allez, je prend un peu d'avance: de toute façon avec systemd ils ne seront démarrés qu'à la demande :P
        
        J'ai l'impression que Debian ne cible pas les "vieux barbus de la vieille école", mais un équilibre entre eux et le néophyte pur. Si je devait conseiller une distro à quelqu'un qui ne connaît pas linux mais est capable de comprendre ce qu'il fait et de lire le man, je pense que Debian est un bon départ: c'est une distro qui ne nécessite pas énormément de maintenance, mais qui permets malgré tout un bon niveau de personnalisation (bon, maintenant je pense qu'il va être temps pour moi de passer à autre chose, mais c'est pas le sujet)
        
        [^] # Re: Point par point
        
        Posté par vv222 (site web personnel) le 11 septembre 2014 à 14:26. Évalué à 1.
        
        tous les utilisateurs ne savent pas forcément de quoi ils ont besoin, et installer automatiquement les recommended permets, j'imagine, d'éviter que les gens disent que ça ne marche pas out-of-the-box… même si pour moi Debian ne devrait pas cibler ce type de public (qui ne fait pas attention à ce qu'il installe ni aux "conseils" du système)
        
        https://www.debian.org/
        titre de la page : « Debian -- Le système d’exploitation universel »
- [^] # Re: Point par point
  
  Posté par Michaël (site web personnel) le 08 septembre 2014 à 21:16. Évalué à 10.
  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!
  - [^] # Re: Point par point
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 08 septembre 2014 à 22:48. Évalué à 1.
    
    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).
    - [^] # Re: Point par point
      
      Posté par Michaël (site web personnel) le 08 septembre 2014 à 23:19. Évalué à 10.
      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é.
      - [^] # Re: Point par point
        
        Posté par Axel le 09 septembre 2014 à 14:38. Évalué à 4.
        
        Visiblement c'est peine perdue.
        C'est un peu comme si tu demandes à un footballeur de t'apprendre le foot, il se contentera de te dire "hop passement de jambe double-contact tir et but !", alors qu'un entraîneur saura se mettre à ta place et s'y prendra différemment (et mieux).
        
        [^] # Re: Point par point
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 15:55. Évalué à 1.
        
        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 !
        
        [^] # Re: Point par point
        
        Posté par Mildred (site web personnel) le 10 septembre 2014 à 09:46. Évalué à 6.
        
        Et pour répondre à la question, non, je n'ai pas essayé autre chose, faute de raison de le faire !
        
        Tu devrais essayer :) mais tu risque ne de plus faire beaucoup de paquets Debian…
      - [^] # Re: Point par point
        
        Posté par symoon le 09 septembre 2014 à 21:06. Évalué à 3.
        
        Il y a également:
        https://www.debian.org/doc/devel-manuals#packaging-tutorial
- [^] # Re: Point par point
  
  Posté par Mildred (site web personnel) le 10 septembre 2014 à 09:39. Évalué à 6.
  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.
  
  On comprend mieux pourquoi chaque paquet debian est un fork du projet upstream avec une multitude de patches.
  
  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.
  
  Il y a quand même pas mal de complexité ajoutée pour rien. Je suis habituée à la compilation sur ArchLinux, et c'est redoutable de simplicité. Si tu veux créer un paquet, il tu suffit:
  - de créer un fichier PKGBUILD (a partir d'un template) dans un dossier vide (mkdir PKGNAME && cd PKGNAME && cp ~/Template/PKGBUILD .)
  - d'y coller l'URL de téléchargement du tarball sources upstream ($EDITOR PKGBUILD)
  - inscrire les instructions pour compiler le paquet
  - exécuter makepkg -g
  Lorsqu'on a le bon template, créer un paquet relativement propre peut se faire en 5 minutes grand maximum. Et ce mode de fonctionnement n'empêche pas de faire du packaging propre en splittant un paquet source en plusieurs paquets binaires. Cela n'empêche pas non plus de respecter la FHS.
  
  En comparatif, on a:
  - ArchLinux: créer un paquet se fait en 5 commandes shell
  - Debian: largement plus d'une dizaine (wget pour télécharger, tar pour décompresser, mkdir debian, echo 9 >debian/compat, …)
  J'ai choisi mon camp
  - [^] # Re: Point par point
    
    Posté par Chris K. le 10 septembre 2014 à 15:56. Évalué à 5.
    
    Je serai très surpris de pouvoir mettre à jour une Arch pendant 14 ans sur 6 versions majeures - comme j'ai pu le faire avec Debian - tout en conservant un système fonctionnel et propre. Même si c'est loin d'être évident pour le mainteneur au final la qualité du packaging Debian est bien là et c'est du solide ! :)
    - [^] # Re: Point par point
      
      Posté par jolitorax le 10 septembre 2014 à 21:16. Évalué à 5.
      
      Juste 3 versions majeures pour certains de nos serveurs. Ils passeront encore un version ou peut être deux avant d'être mis au rebut.
      
      Chez moi, je ne suis pas trop loin des 8 ans en testing. Le PC est toujours à jour et fonctionne bien. Franchement j'apprécie, c'est l'une des force de Debian.
    - [^] # Re: Point par point
      
      Posté par groumly le 13 septembre 2014 à 07:52. Évalué à 0.
      
      Mouais. Tu peux mettre a jour windows depuis dos 1 (30 ans et 15 versions majeures), macosx depuis 10.0 (encore que la, c'est le hard qui va bloquer ppc-> x86), et ils se font pas chier avec des packagings aussi complique.
      Et surtout, un installeur ecrit ya dix ans s'installe toujours aussi bien pour la grande majorite des cas, bon courage pour faire ca sous n'importe quelle distro entre 2 versions majeures.
      
      Alors bon, les stabilites et proprete des mises a jours de debian, tu m'excuseras, mais voila quoi. Oui, ca marche, encore heureux, et ca a rien de fabuleux.
      
      Linuxfr, le portail francais du logiciel libre et du neo nazisme.
      - [^] # Re: Point par point
        
        Posté par Chris K. le 13 septembre 2014 à 11:16. Évalué à 5. Dernière modification le 13 septembre 2014 à 11:18.
        
        Mouais. Tu peux mettre a jour windows depuis dos 1 (30 ans et 15 versions majeures)
        
        Belle affirmation mais simple question : l'as tu fait ?
        Parce que si c'est ce que le marketing crosoft te racontes je peux t'assurer que dans la vrai vie™ ça ne fonctionne pas.
        Déjà tenir un windows d'aujourd'hui 5 ans en utilisation normale c'est plutôt correct.
        Monter en version depuis 3.11 ou 95 ça fonctionne peut être dans une VM en condition de labo. En utilisation réelle, excuses-moi mais c'est vraiment du délire.
        J'ai eu beaucoup de mises à jour de versions windows qui ne se sont pas bien passées et qui donnaient un système encore plus instable que lorsqu'il était installé à partir de zéro, ce qui à une époque relevait de l'exploit.
        Et le moins qu'on puisse dire, surtout pour les anciennes versions, c'est que le résultat produit était très loin d'être propre : le système de fichier était plein de cochonneries des anciennes versions (plusieurs Go d'écart).
        A tel point qu'aujourd'hui encore je fais plutôt une réinstallation qu'une mise à jour quand c'est possible.
        
        Et surtout, un installeur ecrit ya dix ans s'installe toujours aussi bien pour la grande majorite des cas, bon courage pour faire ca sous n'importe quelle distro entre 2 versions majeures.
        
        Vu la différence entre un installeur et un package, oui il est plus dur de reprendre un vieux package qu'un viel installeur windows à cause des dépendances. Sinon en faisant un tar avec toutes les libs on peut faire aussi bien.
        Les packages deb/rpm ne laissent pas autant de déchets après désinstallation. J'ai fait du packaging sauce crosoft pendant deux ans et les packages des éditeurs que l'on modifiait étaient loin d'être tous propres.
        
        PS: Ce n'est pas moi qui t'ai moinssé.
      - [^] # Re: Point par point
        
        Posté par Moonz le 13 septembre 2014 à 11:30. Évalué à 9.
        
        et ils se font pas chier avec des packagings aussi complique
        
        D’un autre côté quand on a pas de système de package avec gestion des dépendances c’est plus facile de gérer les mises à jour de l’arbre complet, effectivement.
  - [^] # Re: Point par point
    
    Posté par symoon le 10 septembre 2014 à 22:43. Évalué à 4.
    
    Debian: largement plus d'une dizaine (wget pour télécharger, tar pour décompresser, mkdir debian, echo 9 >debian/compat, …)
    
    Ben non, désolé, regarde dh_make il crée l'arborescence debian pour toi. cf man dh_make:
    DEBFULLNAME="John Doe" dh_make --email contact@example.com --copyright=bsd --file ../foo.tar.gz
    
    Je comprends que certains aient été traumatisés par les vielles versions de debhelper, mais les temps ont changés..
  - [^] # Re: Point par point
    
    Posté par freem le 11 septembre 2014 à 12:45. Évalué à 1.
    En comparatif, on a:
    ArchLinux: créer un paquet se fait en 5 commandes shell
    Debian: largement plus d'une dizaine (wget pour télécharger, tar pour décompresser, mkdir debian, echo 9 >debian/compat, …
    
    Pas besoin de télécharger le tarball des sources, ni de le dépaqueter avec arch?
    Enfin bon… puisque tu te bases sur un modèle Arch pour dire que la procédure brute de Debian est pourrie, alors, une question:
    qu'est-ce qui t'empêche d'écrire un script qui, en ne prenant que l'URI de la tarball:
    - télécharge une tarball
    - la décompresse
    - y crée un dossier debian, en fonction d'un modèle "bien fichu"
    D'ailleurs, je serais assez surpris qu'aucun outil n'existe encore pour faire des trucs aussi triviaux de manière automatique…
    - [^] # Re: Point par point
      
      Posté par Moonz le 11 septembre 2014 à 17:13. Évalué à 6.
      
      Pas besoin de télécharger le tarball des sources, ni de le dépaqueter avec arch?
      
      Non, ça fait partie du PKGBUILD (l’équivalent du debian/rules), les sources sont listées dans une variable source, téléchargées et décompressées automatiquement lors de la création du paquet (avec vérification des checksums, support de sources git/svn/mercurial…)
      - [^] # Re: Point par point
        
        Posté par kna le 11 septembre 2014 à 18:09. Évalué à 3.
        
        et pour savoir quoi mettre dans ton PKGBUILD, tu télécharges les sources pour lire le README…
        
        [^] # Re: Point par point
        
        Posté par Mildred (site web personnel) le 12 septembre 2014 à 12:42. Évalué à 2.
        
        Non, en général tu as la doc en ligne.
        
        Ou une fois que makepkg a téléchargé les sources, tu regardes dedans comment ça marche et tu complètes ton PKGBUILD
# Git

Posté par barmic le 08 septembre 2014 à 17:22. Évalué à 9. Dernière modification le 08 septembre 2014 à 17:23.

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: comme mon krims-krams est en RCS, je dois faire un checkout à chaque fois que je fais une mise-à-jour du système, et si par hasard j'ai choisi git… hm pas top.

La majorité des packagers utilisent git faut pas croire. Je ne vois pas en quoi ça pose un problème tu peut avoir 2 serveurs liés à ton dépôt local : upstream qui est un checkout du projet initial et un à toi que tu met où tu veux. Chacun a une branche à lui (par exemple upstream -> master) et toi tu fais un pull sur master depuis upstream et tu rebase ta banche package. tu peut avoir beacoup plus d'info ici :

https://wiki.debian.org/PackagingWithGit

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

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Git
  
  Posté par Michaël (site web personnel) le 08 septembre 2014 à 21:30. Évalué à 3.
  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!
  - [^] # Re: Git
    
    Posté par barmic le 08 septembre 2014 à 23:55. Évalué à 5.
    
    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.
    
    Oui mais du coup tu perd le lien entre une version des sources et ton packaging. Sincèrement l'espace disque est un faux problème, tu ne trouvera pas à part à vraiment chercher de mémoire morte pour les quels ça fait une différence sensible. Il faut que tu suive le projet sur des années pour vraiment le sentir, si le packaging te pose un problème commence à régler les problèmes actuels avant de te poser des questions sur des cas hypothétiques (si je veux repackager le logiciel alors que je suis sur une machine qui n'a que 16Kio d'espace libre…).
    
    Pour ce qui est du rapport signal/bruit, le fait de tout mettre dans un répertoire fait que, dans les faits tu ne va pas aller dans le répertoires des sources, tu travaillera toujours dans le dossier debian/ où tu ne verra jamais autre chose que tes fichiers.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Git
      
      Posté par Michaël (site web personnel) le 09 septembre 2014 à 00:50. Évalué à 4.
      
      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?
      - [^] # Re: Git
        
        Posté par barmic le 09 septembre 2014 à 09:00. Évalué à 5. Dernière modification le 09 septembre 2014 à 09:00.
        
        Du coup, comment ça marche? On crée une branche debian dans laquelle on merge masterà chaque nouvelle version?
        
        Oui c'est ce que je décris dans mon commentaire racine de ce fil. C'est surprenant au début d'avoir 2 branches avec autant de différence, mais c'est très pratique.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Git
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 09:19. Évalué à 4.
        
        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.
      - [^] # Re: Git
        
        Posté par mrr le 12 septembre 2014 à 14:34. Évalué à 2.
        
        J'ai pas très bien compris moi non plus…
        
        Sinon, qu'est-ce qui t'empêche de simplement versionner l'intérieur du dossier debian (dans un dépot séparé ou dans une branche orpheline) et de l'ajouter ensuite aux sources comme sous-module ?
        
        Envoyé depuis ma Debian avec Firefox
# Debian toujours en avance.

Posté par reynum (site web personnel) le 08 septembre 2014 à 17:24. Évalué à 10.

Tu me diras, en cas d'hiver nucléaire, je serais bien content de les avoir ces ChangeLogs

C'est là toute la force de Debian ils savent anticiper :-D

kentoc'h mervel eget bezan saotred
# Et pourtant il y a bien trop de packages

Posté par Salk le 08 septembre 2014 à 17:25. Évalué à -9.

Le paradoxe est que cette apparente complexité n'empêche pas Debian d'avoir bien trop de packages pour que l'utilisateur y retrouve ses petits.

A quoi bon simplifier en pareil cas ?
- [^] # Re: Et pourtant il y a bien trop de packages
  
  Posté par freem le 08 septembre 2014 à 17:54. Évalué à 10.
  
  trop de packages pour que l'utilisateur y retrouve ses petits.
  
  Source?
  Il est au contraire hyper simple de retrouver ses petits dans Debian pour un utilisateur Debian, même sans environnement graphique, notamment grâce à aptitude. Je trouve, et je ne suis pas le seul, que le treeview d'aptitude permets de s'y retrouver simplement et de découvrir les paquets correspondant au rôle que l'on cherche (et encore plus si l'on a installé le paquet debtags), et les 3 fenêtres d'informations du paquet surligné permettent d'avoir en très peu de temps une idée de "à quoi sert le paquet", "l'état du paquet" et "pourquoi est-il, ou non, installé". Cet outil fournit également un moyen très simple de manipuler son système à l'envie, voire de le casser si on le souhaite.
  Vraiment, je ne peux qu'être en désaccord… mais bon, en même temps je réponds à un troll…
  
  Je serai curieux de savoir le nom des logiciels du même type des distributions utilisant d'autres systèmes de packages?
  - [^] # Re: Et pourtant il y a bien trop de packages
    
    Posté par xcomcmdr le 08 septembre 2014 à 18:59. Évalué à 3. Dernière modification le 08 septembre 2014 à 22:48.
    Je serai curieux de savoir le nom des logiciels du même type des distributions utilisant d'autres systèmes de packages?
    
    Pour Archlinux :
    Pacman et pkgfile (qui utilise les métadonnées de pacman et dépend de pacman)
    
    Quelques exemples :
    
    à quoi sert le paquet
    
    pacman -[S|Q]i[i] <foo>
    
    (notamment la ligne "Description")
    
    l'état du paquet
    
    J'imagine si c'est pour savoir s'il est installé ou non. Là je trouve que ce n'est pas très direct
    1. pacman -Qs <package_pas_local> ne renvoie rien (ça veut dire qu'il n'est pas installé)
    2. pacman -Qi <package_pas_local> propose la complétion chez moi. Si pas de complétion ou erreur comme quoi le paquet n'a pas été trouvé, pas installé
    Pour le reste des infos, la commande pacman -Qi[i] <bar> remplit bien son office.
    Il y a aussi la commande pacman -Qk <bar> pour vérifier un paquet, ou pacman -Qkk pour tous les vérifier.
    
    pourquoi est-il, ou non, installé
    
    pacman -[S|Q]i[i] <bar>
    (notamment la ligne "Motif d'installation")
    
    Quant à savoir pourquoi il n'est pas installé, je ne vois pas le but ni la commande. On peut savoir les conflits avec -[Q|S]ii <foo> mais sinon…
    
    Après, il y aussi la page Pacman Tips qui liste pas mal de scripts/one-liners/outils tiers pour étendre/compléter pacman.
    
    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
    - [^] # Re: Et pourtant il y a bien trop de packages
      
      Posté par xcomcmdr le 08 septembre 2014 à 19:06. Évalué à 2.
      
      tout ce qui est entre signe inférieur/signe supérieur ne s'affiche pas, du coup le message a parfois un sens assez différent. Si un modérateur pouvait passer par là pour enlever ces signes…. Merci !
      
      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
    - [^] # Re: Et pourtant il y a bien trop de packages
      
      Posté par freem le 09 septembre 2014 à 12:21. Évalué à 2.
      
      Je viens de regarder des screenshot, j'espère être tombé sur les bons… mais ils corroborent ce que je pensais, à savoir que pacman est l'équivalent d'apt-, avec le très très gros avantage d'être en couleur on dirait (pour pacman, pas apt-).
      Pour pkgfile, j'ai un très gros doute sur les screen que j'ai trouvés, mais ça semble être un outil graphique?
      
      Pour le coup, ils n'ont rien à voir avec aptitude, ni l'un ni l'autre.
      Enfin, si, aptitude en ligne de commande peut être comparé à pacman, mais ça semble s'arrêter là. Perso, je parlais plutôt d'aptitude en mode ncurses, parce que pour être honnête, je ne vois que peu d'intérêt à l'utiliser en ligne de commande, vue la lourdeur du truc (et pourtant j'adore cet outil…).
      
      Le gros intérêt d'aptitude comparé à d'autres logiciels comme synaptic c'est qu'en plus d'avoir une IHM très bien foutue (j'ai testé synaptic il y à longtemps, c'était très pénible à utiliser), c'est du ncurses, donc utilisable via ssh sur une machine sans serveur graphique. Et avoir une interface en ncurses permets vraiment de gagner du temps, surtout au début quand on viens du monde windows… comme ça à été mon cas. Même maintenant, je m'en sers encore parce que je trouve ça tout de même bien pratique d'avoir en un clin d'œil toutes les infos dont j'ai besoin sur une liste de paquets, et qu'il permets aussi une simplicité impressionnante quand il s'agit de choisir entre plusieurs alternatives.
      Enfin, je suis pas un commercial, mais j'adore vraiment cet outil. Dommage qu'il ne soit pas possible de faire sauter ce p***** de solver et qu'il soit aussi lent à démarrer. Entres autres défauts (l'outil est résolument mono-threadé, et n'exploite pas à 100% les informations liées aux paquets, par exemple).
      
      Quant à savoir pourquoi il n'est pas installé,
      
      L'intérêt je ne le vois pas, mais je me suis aussi très mal exprimé sur ce coup :)
      En fait, aptitude se divise (par défaut) en 2 zones d'écrans: l'une avec une arborescence (1er niveau: paquets pouvant être MaJ, paquets installés, non installés, obsolètes ou locaux, virtuels, tâches… 2ème niveau: section genre admin, devel, lib… 3ème niveau: main/contrib/non-free, et enfin les noms des paquets) l'autre avec des infos sur le paquet sélectionné, qui à 3 onglets: description, dépendances liées (info dont je ne me sers jamais, et qui permets de voir pourquoi ça pourrait être installé, le point sur lequel je me suis mal exprimé) et pourquoi c'est installé (je trouve cet écran un "poil" redondant avec celui d'avant, d'une certaine façon).
      
      Après, c'est sûr, ce n'est pas scriptable facilement une IHM ncurses, mais je parlait au niveau utilisateur. Si j'avais besoin de scripter des actions sur les paquets, je jouerais plutôt avec apt-* et dpkg.
      - [^] # Re: Et pourtant il y a bien trop de packages
        
        Posté par Reihar le 09 septembre 2014 à 13:48. Évalué à 1.
        
        pkgfile est un outil en cli. Aussi, à ma connaissance, il n'y a pas d'interface à pacman en ncurses.
      - [^] # Re: Et pourtant il y a bien trop de packages
        
        Posté par barmic le 09 septembre 2014 à 13:57. Évalué à 7.
        
        Je viens de regarder des screenshot, j'espère être tombé sur les bons… mais ils corroborent ce que je pensais, à savoir que pacman est l'équivalent d'apt-, avec le très très gros avantage d'être en couleur on dirait (pour pacman, pas apt-).
        
        apt (tout court) est vraiment pas mal pour ça (entre autre).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Et pourtant il y a bien trop de packages
        
        Posté par vv222 (site web personnel) le 11 septembre 2014 à 14:43. Évalué à 7. Dernière modification le 11 septembre 2014 à 14:44.
        
        apt-get lui-même le fait très bien, apt n’étant presque qu’un apt-get déguisé avec des options par défaut différentes.
        En particulier les options suivantes à ajouter à apt.conf permettent d’activer certains comportements d’apt avec apt-get :
        _la barre de progression (en couleurs) : DPKG::Progress-Fancy 1;
        _la couleur : APT::Color 1;
        _l’installation de nouveaux paquets lors des mises-à-jours : APT::Get::Upgrade-Allow-New 1;
        
        [^] # Re: Et pourtant il y a bien trop de packages
        
        Posté par barmic le 11 septembre 2014 à 14:57. Évalué à 3.
        
        Je ne connaissais pas, c'est dispo en stable ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Et pourtant il y a bien trop de packages
        
        Posté par vv222 (site web personnel) le 11 septembre 2014 à 20:35. Évalué à 1.
        
        Certains des effets uniquement, si je ne me plante pas l’installation de nouveaux paquets lors des mises-à-jour est disponible, mais par contre je crois que ni la barre de progression ni la coloration ne sont implémentées.
        
        [^] # Re: Et pourtant il y a bien trop de packages
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 11 septembre 2014 à 17:32. Évalué à 4.
        
        C'est bon ça, merci !
  - [^] # Re: Et pourtant il y a bien trop de packages
    
    Posté par MCMic (site web personnel) le 09 septembre 2014 à 11:16. Évalué à 5.
    
    Franchement, habitué à yaourt/pacman sous Arch, je suis complètement perdu sous Debian…
    La commande pour installer ou chercher n’est pas là même (apt-get vs apt-cache), 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, …
    - [^] # Re: Et pourtant il y a bien trop de packages
      
      Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 11:22. Évalué à 7.
      
      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.
      - [^] # Re: Et pourtant il y a bien trop de packages
        
        Posté par Anonyme le 09 septembre 2014 à 11:38. Évalué à 6.
        
        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.
        
        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.
        
        [^] # Re: Et pourtant il y a bien trop de packages
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 11:43. Évalué à 1.
        
        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.
        
        [^] # Re: Et pourtant il y a bien trop de packages
        
        Posté par Anonyme le 09 septembre 2014 à 16:00. Évalué à 7.
        
        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.
        
        Peu importe ce qui est fait derrière pour l'obtenir, on demande la meme info. Dans le cas de rpm par exemple, toutes les options pour obtenir une info sur un package peuvent s'appliquer aussi bien sur un package installé que sur un fichier rpm. Il y a une option pour dire si l'on parle d'un package installé ou non.
      - [^] # Re: Et pourtant il y a bien trop de packages
        
        Posté par MCMic (site web personnel) le 09 septembre 2014 à 15:03. Évalué à 2.
        
        Bon, donc idéalement faudrait juste qu’ils rajoutent apt list et apt owner qui correspondraient à dpkg -S et -L. (Et, oui, je parlais bien de lister les fichiers d’un paquet installé, je sais pas si on peut pour un paquet non-installé sous Arch non plus j’en ai jamais eu besoin)
        
        [^] # Re: Et pourtant il y a bien trop de packages
        
        Posté par barmic le 09 septembre 2014 à 15:19. Évalué à 8.
        
        Sous debian c'est possible avec apt-file (qui se base sur l'index des dépôts).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Et pourtant il y a bien trop de packages
        
        Posté par MyLordAngus le 18 septembre 2014 à 13:30. Évalué à 1.
        
        (Et, oui, je parlais bien de lister les fichiers d’un paquet installé, je sais pas si on peut pour un paquet non-installé sous Arch non plus j’en ai jamais eu besoin)
        
        Pour info, sous Arch tu peux utiliser pkgfile pour rechercher les fichiers d'une paquet non installé sur le système.
        
        pgfile $file_name
        
        pour rechercher quel(s) paquet(s) contient le fichier $file_name
        
        pkgfile -u
        
        pour mettre à jour la base de données locale (à placer dans un cron idéalement).
    - [^] # Re: Et pourtant il y a bien trop de packages
      
      Posté par barmic le 09 septembre 2014 à 11:23. Évalué à 2.
      
      La commande pour installer ou chercher n’est pas là même (apt-get vs apt-cache)
      
      Demain (avec Debian Jessie) remplacé par apt tout court (il restera toujours dpkg).
      
      savoir à quel paquet appartient un fichier
      
      C'est disponible de base : dpkg -S /chemin/fichier
      
      lister les fichier d’un paquet
      
      Pour les paquets installé c'est disponible de base : dpkg -L paquet
      
      Debian maintient une distinction entre dpkg et apt, je ne sais pas si c'est une bonne chose. C'est la même chose dans le monde rpm, avec rpm, urpm/rpmi/yum. Personnellement je ne vois pas bien la grosse différence entre un apt-cache et apt cache.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Et pourtant il y a bien trop de packages
      
      Posté par Padishah le 09 septembre 2014 à 13:49. Évalué à 1.
      
      aptitude (re)install
      aptitude search
      aptitude show
      etc.
    - [^] # Re: Et pourtant il y a bien trop de packages
      
      Posté par Marotte ⛧ le 09 septembre 2014 à 15:33. Évalué à 0.
      
      savoir à quel paquet appartient un fichier
      
      Si le package est installé dpkg -S <fichier>
      - [^] # Re: Et pourtant il y a bien trop de packages
        
        Posté par MCMic (site web personnel) le 09 septembre 2014 à 15:50. Évalué à 2.
        
        Ya juste deux réponses avant la tienne qui donnent déjà cette info :-P
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 11 septembre 2014 à 11:17. Évalué à 2.
      
      Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Et pourtant il y a bien trop de packages
  
  Posté par Maxime (site web personnel) le 09 septembre 2014 à 10:04. Évalué à 2.
  
  Il n'y a jamais trop de packages. Par contre avoir une appli de plus haut niveau capable de suggestion, avec un moteur de recherche intelligent et qui ferait des appels à apt en arrière plan, ce serait sympa. Genre un bon app store comme on trouve sur les plateformes mobiles.
  - [^] # Re: Et pourtant il y a bien trop de packages
    
    Posté par freem le 09 septembre 2014 à 12:21. Évalué à 0.
    
    Aptitude est ton amie.
    - [^] # Re: Et pourtant il y a bien trop de packages
      
      Posté par Maxime (site web personnel) le 09 septembre 2014 à 13:33. Évalué à 3.
      
      J'utilise aptitude mais ce n'est pas comparable à un « store ». J'aimerais avoir accès aux avis des utilisateurs par exemple. Si j'ai 10 logiciels qui correspondent à ma recherche, j'affine avec les commentaires. Et puis pour certains logiciels, j'aimerais avoir accès à des captures d'écran histoire de voir à quoi ça ressemble avant de l'installer.
      
      Actuellement je suis obligé de chercher sur internet pour trouver le logiciel puis voir s'il est effectivement dispo dans ma distro et sous quel nom.
      - [^] # Re: Et pourtant il y a bien trop de packages
        
        Posté par Hobgoblins Master (Mastodon) le 09 septembre 2014 à 13:52. Évalué à 5.
        
        Pour les « avis » des utilisateurs, je ne sais pas, quoi que le BTS… Par contre pour les capture d’écran, il y a http://screenshots.debian.net qui est utilisé par au moins Synaptic et Ubuntu Software Center pour le moment. Par exemple :
- [^] # Re: Et pourtant il y a bien trop de packages
  
  Posté par Grunt le 09 septembre 2014 à 10:41. Évalué à 1.
  
  Ça tombe très bien, l'utilisateur n'a aucune raison de regarder la liste des packages.
  Il faut les droits administrateur (!= utilisateur) pour installer et désinstaller.
  
  THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# mouaif

Posté par Axel le 08 septembre 2014 à 17:47. Évalué à 10.

L'empaquetage pour Debian est à la distribution de logiciels ce que git est aux gestionnaire de version de code ou ce que systemd est aux gestionnaires de démarrage.
Une usine à gaz, pleine de fonctions, mais pas intuitive pour un sou, avec une documentation imbitable même pour les tâches les plus simples, et dont la prise en main prend des heures (ce qui en soit est un frein énorme et n'a aucune vraie valeur ajoutée professionnelle)

Peu de commentaires et pourtant la majorité te disent que c'est pour ton bien ou que c'est normal (kikou tanguy). Surement parce qu'eux savent tout ce qu'il faut savoir pour s'en sortir et baignent dedans. Toujours est-il que faire un paquet pour la concurrence est plus simple.

Et pourtant, je baigne dedans et je te rejoins. Je fais des paquets Debian depuis Etch, et l'écosystème et surtout sa doc n'a que peu changé. Les documentations sont éparses, laconiques, imprécises et aucune "trajectoire" standard ne te semblera émerger de tout ce que tu pourras lire. Tantôt des wikis, tantôt des pages web, tantôt des man. Quant à la fraîcheur des infos…
Globalement, les mécanismes simples sont mal expliqués et les trucs compliqués même pas abordés. Si ton paquet ne concerne pas un logiciel basé sur autotools, tu peux t'accrocher. Et si en plus tu veux mettre les pieds dans l'hébergement et la gestion d'un dépôt, tu passes quelques heures de plus.

Alors forcément, une fois que tu as passé des heures et des heures à lire, test, bricoler pour avoir un paquet, je comprends que certains ne veulent pas trop cracher sur la soupe qui leur a été tellement difficile à obtenir. Quant à la motivation pour éviter qu'un autre ne tombe dans les mêmes travers et écrire une bonne fois pour toute une vraie documentation, elle disparaît vite, tellement la charge de travail est énorme.

Donc, pour répondre à ta question : C'est archaïque probablement parce que chez Debian personne n'a mis un point d'honneur à rendre accessible leurs environnements de dev. Participer à Debian est laborieux en partie à cause de ça justement, ça a des avantages et des inconvénients.
- [^] # Re: mouaif
  
  Posté par 🚲 Tanguy Ortolo (site web personnel) le 08 septembre 2014 à 18:02. Évalué à 3.
  
  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.
  - [^] # Re: mouaif
    
    Posté par Axel le 08 septembre 2014 à 18:06. Évalué à 5.
    
    hop hop hop je t'arrête tout de suite, on n'en est pas à donner des opinions ou des avis : 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.
    
    Perso c'est une caractéristique qui non seulement me rebute mais qui en plus est un vrai défaut pour un logiciel, et là oui c'est une opinion.
    - [^] # Re: mouaif
      
      Posté par xcomcmdr le 08 septembre 2014 à 19:23. Évalué à -2. Dernière modification le 08 septembre 2014 à 19:27.
      
      systemd
      
      Systemd n'est pas plus complexe pour un débutant. Oui, il a plus de lignes de code, mais il s'administre tout aussi aisément (voire plus facilement, je pense notamments aux units qui s'écrivent en 30 secondes alors que j'ai jamais été très adepte du shell), et avec plus de fiabilité (systemd m'informe bien mieux sur l'état des services, et les contrôlent sans s'embêter grâce aux control groups du kernel).
      
      Quand à l'usage au quotidien : d'abord, il n'y a pas de raison pour un débutant d'avoir plus affaire à systemd qu'il n'avait affaire à SysV. Si ça marche (et 99% du temps sytemd est fiable), le débutant n'y verra que du feu.
      
      Au niveau de l'implémentation, systemd est compatible avec les scripts. Mais ça, ça concerne plus les mainteneurs que l'usager débutant.
      
      Au niveau des commandes, avant on utilisait systemctl, après on utilise… systemctl.
      poweroff/halt/reboot etc sont même toujours bien compris.
      
      Bref, non seulement le passage à systemd est transparent (comme ce sera le cas quand Ubuntu y passera) mais en plus celui qui touche à systemctl, c'est difficile de le décrire comme débutant.
      
      git
      
      git est moins simple que svn, mais offre bien plus que svn. Des fonctionnalités si utiles que personne ne veut repasser à SVN.
      
      le système de packaging Debian
      
      Il est plus complexe que d'autres, mais il offre plus facilement certains services que pacman. Par exemple :
      
      Display packages which conflict with given expression (often package). Search can be used as well to mimic this function.
      
      (none) repoquery --whatconflicts aptitude search '~Cpattern' IN PROGRESS
      
      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
      - [^] # Re: mouaif
        
        Posté par Mildred (site web personnel) le 10 septembre 2014 à 09:59. Évalué à 1.
        
        Il est plus complexe que d'autres, mais il offre plus facilement certains services que pacman. Par exemple :
        
        Display packages which conflict with given expression (often package). Search can be used as well to mimic this function.
        
        (none) repoquery --whatconflicts aptitude search '~Cpattern' IN PROGRESS
        
        Si c'est la seule raison qui pousse a avoir un système qui prend 10x plus de temps (et je pense être en dessous de la réalité en disant ça) pour créer un paquet, alors ça doit sûrement valoir le coup.
        
        [^] # Re: mouaif
        
        Posté par xcomcmdr le 10 septembre 2014 à 13:17. Évalué à 4.
        
        Faut arrêter d'être binaire !
        
        J'utilise Archlinux tous les jours.
        
        Mais ce n'est pas pour autant que je méprise le reste.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
    - [^] # Re: mouaif
      
      Posté par bubar🦥 (site web personnel) le 08 septembre 2014 à 19:32. Évalué à 2.
      
      +1.
      Mais un package d'une distrib n'est pas un package autonome comme un macport, c'est un élément d'une infra.
      Et ça aussi, c'est un fait.
      
      Un autre fait est qu'il n'y a pas d'intérêt à utiliser le packaging distro si c'est pour ne pas intégrer le package. On peut filer un tarball avec tout ce qui va bien dedans, c'est pas comme si un .desktop était la mer à boire pour donner à l'utilisateur un icone à cliquer.
      - [^] # Re: mouaif
        
        Posté par devnewton 🍺 (site web personnel) le 08 septembre 2014 à 23:39. Évalué à 2.
        
        On peut filer un tarball avec tout ce qui va bien dedans, c'est pas comme si un .desktop était la mer à boire pour donner à l'utilisateur un icone à cliquer.
        
        Ça dépends des utilisateurs… La plupart des gens ne savent pas ce qu'est une archive.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
    - [^] # Re: mouaif
      
      Posté par Michaël (site web personnel) le 08 septembre 2014 à 20:20. Évalué à 3.
      
      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!
      - [^] # Re: mouaif
        
        Posté par freem le 09 septembre 2014 à 12:25. Évalué à 4.
        
        et les branches, oublie les!
        
        Et du coup les gens ont du faire du copier/coller dans des dossiers trunk, tags et branch. Supayr.
- [^] # Re: mouaif
  
  Posté par Adrien le 08 septembre 2014 à 19:50. Évalué à 0.
  
  Les documentations sont éparses, laconiques, imprécises et aucune "trajectoire" standard ne te semblera émerger de tout ce que tu pourras lire
  
  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.
  
  Sinon on a déjà payé pour libérer « les cahiers de l'admin », qui propose une explication que je trouve assez claire sur la construction de paquet…
  - [^] # Re: mouaif
    
    Posté par Michaël (site web personnel) le 08 septembre 2014 à 20:22. Évalué à 6.
    
    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!)
- [^] # doc de git?
  
  Posté par Reihar le 09 septembre 2014 à 09:52. Évalué à 1.
  
  Tu as eu des problèmes avec la doc de git? J'ai appris à m'en servir avec la doc officielle et je n'ai jamais eu de problèmes. Je l'ai trouvée lisible et bien organisée.
  - [^] # Re: doc de git?
    
    Posté par Mildred (site web personnel) le 10 septembre 2014 à 10:01. Évalué à 1.
    
    Tu as eu des problèmes avec la doc de git? J'ai appris à m'en servir avec la doc officielle et je n'ai jamais eu de problèmes. Je l'ai trouvée lisible et bien organisée.
    
    C'est vrai, mais les commandes git ne sont pas aussi bien organisées, elles.
    http://linuxfr.org/users/chat_de_sorciere/journaux/pourquoi-ecrire-un-package-debian-est-il-si-complique#comment-1560055
    - [^] # Re: doc de git?
      
      Posté par freem le 11 septembre 2014 à 12:45. Évalué à 6.
      
      Mouai.
      
      Alors, franchement, j'ai "formé" un collègue à l'utilisation basique de git, ça m'a pris 1H. Moi, j'en avais beaucoup plus chié, mais je connais la cause: contrairement à lui, j'avais utilisé svn, qui est centralisé…
      
      Après, je dis pas, pour des choses un peu complexes, ce n'est pas toujours hyper simple. Mais bon, il faut voir le contexte: on ne peut pas avoir un outil complet qui ne soit pas plus complexe qu'un outil qui n'offre que peu de fonctionnalités, je pense.
      
      En tout cas, je constate que ça tape pas mal sur git, mais je n'ai vu aucun autre nom de VCS décentralisé dans les commentaires de cet article…
      Darcs, mercurial, bazaar, fossil par exemple, pourquoi personne ne les soumets en alternatives? Ils sont décentralisés, libres, et ont sûrement chacun des points forts, mais alors, encore une fois, pourquoi personne n'a mis l'un d'eux en opposition à git???
# Pourquoi git est-il un problème?

Posté par freem le 08 septembre 2014 à 18:00. Évalué à 2.

On voit tout de suite l'avantage de ce système: comme mon krims-krams est en RCS, je dois faire un checkout à chaque fois que je fais une mise-à-jour du système, et si par hasard j'ai choisi git… hm pas top.

Tu peux expliciter la stp? Parce que je ne vois aucun souci…
Si tu ne veux pas versioner ton dossier DEBIAN, voire si tu veux utiliser un autre dépôt indépendant, tu peux utiliser le fichier .gitignore et versionner la chose séparément.
Si tu souhaites un truc un peu plus intégré mais malgré tout dans un autre dépôt git, tu peux utiliser les submodules.
Et enfin, tu as aussi la possibilité d'envoyer un patch avec ton dossier à l'upstream, ce qui permettra à quelqu'un de t'aider sur le packaging debian…

Donc, une explication réelle sur le fait que cela pourrait poser problème que le projet soit sous git?
- [^] # Re: Pourquoi git est-il un problème?
  
  Posté par 🚲 Tanguy Ortolo (site web personnel) le 08 septembre 2014 à 18:05. Évalué à 2.
  
  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…).
  - [^] # Re: Pourquoi git est-il un problème?
    
    Posté par freem le 08 septembre 2014 à 18:15. Évalué à 3.
    
    Pour un paquet propre, probablement :) merci pour cette correction. (dans le cas d'un truc que l'on ne souhaite pas s'embêter à publier, pour une raison ou une autre, on peut directement construire le paquet binaire, et là c'est un répertoire DEBIAN qu'il faut. Et comme je n'ai jamais pris le temps de construire des paquets debian propres pour le moment…)
    - [^] # Re: Pourquoi git est-il un problème?
      
      Posté par 🚲 Tanguy Ortolo (site web personnel) le 08 septembre 2014 à 22:52. Évalué à 3.
      
      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.
# KISS - Keep it stupid, simple ;)

Posté par Martin Peres (site web personnel) le 08 septembre 2014 à 19:00. Évalué à 10.
Vive les ebuilds et les PKGBUILDs;

Un exemple de paquet complexe dans arch, Mesa:
J'ai testé plusieurs systèmes d'empaquetage et celui de Arch est vraiment le plus sympa pour moi :) Si on veut plus de puissance, portage est génial avec les EFLAGS!
- [^] # Re: KISS - Keep it stupid, simple ;)
  
  Posté par shingo (site web personnel) le 08 septembre 2014 à 19:13. Évalué à 3.
  
  ArchLinux et ses PKBUILD, j'adhère à 100% ! Mais bon, en fait écrire un paquet pour Debian ce n'est pas compliqué du tout, faut juste suivre les directives comme pour les PKBUILD. Par contre, ce qui est pose problème c'est que chaque distribution à son propre système et ça devient vite un casse tête chinois. Quand je devais proposer des paquets pour chaque distribution de mon jeu, j'ai devais avoir chaque distribution installé dans ma virtual box… Prise de tête…
- [^] # Re: KISS - Keep it stupid, simple ;)
  
  Posté par Michaël (site web personnel) le 08 septembre 2014 à 20:25. Évalué à 3.
  
  Je crois que c'est plutôt “Keep it simple, stupid!” sinon la blague avec “Kiss me, stupid!” ne marche pas trop bien.
  - [^] # Re: KISS - Keep it stupid, simple ;)
    
    Posté par Martin Peres (site web personnel) le 08 septembre 2014 à 22:18. Évalué à 4.
    
    Dame Ned! Tu as raison!
    
    /me va se fouetter avec des outils GNU!
# Travail dans les sources et vérification

Posté par Damien Thébault le 08 septembre 2014 à 21:02. Évalué à 8.

Oui je trouve également que la méthode debian n'est pas à mon goût.

Une des choses qui me déplait le plus est de travailler dans les sources. J'ai fait pas mal d'ebuilds et les information d'empaquetage sont bien séparées des données upstream, ça offre une bonne transparence.

Du côté de debian, c'est beaucoup moins clair, c'est à mon avis plus difficile de voir les différences avec l'upstream et de vérifier si l'archive sur laquelle est basée le paquet est la bonne, alors qu'avec d'autres systèmes on dispose de sha-2 voire de signature gpg !

Du coup à choisir une distribution binaire, debian ne m'a jamais vraiment attiré alors que archlinux est placé plus haut dans mon estime.

Après je ne crache pas dessus non plus, la communauté debian est importante et on arrive à trouver des informations intéressantes sur des bugs dans certains paquets, mais niveau technique des paquets je suis pas trop fan.
- [^] # Re: Travail dans les sources et vérification
  
  Posté par 🚲 Tanguy Ortolo (site web personnel) le 08 septembre 2014 à 22:56. Évalué à -1. Dernière modification le 08 septembre 2014 à 22:58.
  
  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/)
  - [^] # Re: Travail dans les sources et vérification
    
    Posté par Axel le 08 septembre 2014 à 23:29. Évalué à 8.
    
    Peut être qu'à force de le répéter, ça va devenir effectivement simple tout seul par magie, oui.
# Mouaif

Posté par claudex le 08 septembre 2014 à 22:20. Évalué à 6. Dernière modification le 08 septembre 2014 à 22:20.

Je suis loin d'être d'être d'accord avec tes arguments (voir les autres commentaires). Par contre, ce qui me tue avec les paquets Debian, c'est quilt. J'ai un mal fou à l'utiliser correctement. Je vois souvent les gens se plaindre de git mais quilt me semble bien plus compliqué. (en plus, trouve beaucoup moins de doc)

« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: Mouaif
  
  Posté par Michaël (site web personnel) le 08 septembre 2014 à 23:04. Évalué à 10. Dernière modification le 08 septembre 2014 à 23:06.
  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é.
  - [^] # Re: Mouaif
    
    Posté par Effraie (site web personnel) le 09 septembre 2014 à 06:44. Évalué à -2.
    
    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é.
    
    Peut-être que si tu t'étais contenté de simplicité, ça serait passé… mais pour rajouter qualité dans ta phrase, il fallait attendre vendredi…
    
    \Ö<
    - [^] # Re: Mouaif
      
      Posté par Michaël (site web personnel) le 09 septembre 2014 à 08:57. Évalué à 5. Dernière modification le 09 septembre 2014 à 08:58.
      
      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 !
  - [^] # Re: Mouaif
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 09:26. Évalué à 1.
    
    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.
    - [^] # Re: Mouaif
      
      Posté par Zenitram (site web personnel) le 09 septembre 2014 à 09:42. Évalué à 7. Dernière modification le 09 septembre 2014 à 09:45.
      
      mais que tout y a une raison d'être.
      
      Ou pas.
      
      Sérieux, le seul argument que tu as est de dire que la manivelle de démarage disparue de la voiture de 2014, c'est obligatoirement une fonctionnalité en moins pour la voiture car la manivelle a une raison d'être, c'est pas compliqué pour le plaisir, la manivelle est utile promis juré craché.
      
      Démontre-moi ce que tu peux faire avec Debian (deb) que tu ne peux pas faire avec Fedora (rpm, un fichier, simple, qu'on ne met pas obligatoirement dans un package à refaire) plutôt de de dire "c'est évident que complexité rimme avec fonctionalités". Ma voiture de 2014 n'a pas de manivelle (ni même de clé, horreur) et pourtant elle peut démarrer.
      
      Pour le moment, tu t'auto-convaincs, c'est tout. Si au moisn tu disais "c'est historique, on ne veut pas tout casser maintenant et on le fera quand ça sera intenable", mais même pas…
      - [^] # Re: Mouaif
        
        Posté par Adrien le 09 septembre 2014 à 14:17. Évalué à 2.
        
        Démontre-moi ce que tu peux faire avec Debian (deb) que tu ne peux pas faire avec Fedora (rpm, un fichier, simple, qu'on ne met pas obligatoirement dans un package à refaire)
        
        je ne connais pas du tout le packaging Fedora, mais j'ai deux questions du coup :
        – en quoi avoir tout dans un seul fichier est plus simple que dans des fichiers séparés ? Pour un informaticien confirmé, il me semble que c'est pas vraiment en problème mais bon.
        – pour prendre un exemple que je connais, calligra possède une quinzaine de licence différence (GPL, BSD, MIT, etc.) selon les composants. Sous Debian ces licences sont détaillées dans le fichiers debian/copyright, même si c'est loin d'être parfait. Comment ça se passe sous Fedora ? Tu ajoute tout dans le .spec ? C'est pas le bazar ?
        
        [^] # Re: Mouaif
        
        Posté par barmic le 09 septembre 2014 à 14:50. Évalué à 3.
        
        en quoi avoir tout dans un seul fichier est plus simple que dans des fichiers séparés ?
        
        Potentiellement ça pourrait permettre d'avoir une seule syntaxe unifié (mais ce n'est pas le cas du .spec des rpm). D'ailleurs à avoir différentes syntaxe je préfère que ce soit dans plusieurs fichiers, c'est plus agréable à lire (comme c'est plus agréable de séparer le HTML, du CSS, du JS, du code serveur).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Mouaif
        
        Posté par Zenitram (site web personnel) le 09 septembre 2014 à 15:02. Évalué à 3. Dernière modification le 09 septembre 2014 à 15:07.
        
        Je suis pas forcément motivé pour répondre point par point, mais disons en gros qu'on s'en fout assez de savoir si c'est un fichier ou un répertoire (bon, ça fait assez rigolo de savoir que l'information sur le numéro de version fait 4 Ko, ben oui taille d'un secteur sur certains systèmes de fichier, donc le fichier de 1 octet prend un node + un secteur, fun de chez fun le taux d'information utile par rapport à la taille réelle de l'information), mais forcer à mettre le bousin d'un un répertoire hard codé, c'est lourd (je pense à comment je dois gérer le bousin avec OBS, et en plus OBS m'oblige à mettre à jour à la mano le MD5 sinon il rale si je laisse vide, bref vraiment pas pratique en automatisation, du moins comme OBS doit le gérer par rapport à RPM ou Arch), par exemple.
        
        Et si tu n'as pas suivi, le principal reproche est le manque de documentation unifiée, tu interoge 10 mainteneurs, ils utilisent 10 outils différents et le leur est le meilleur, évidement, sans qu'on te dise vraiment comment faire au mieux quand tu découvres (tiens, ça ressemble au maxi bordel apt-get vs aptitude, le truc très chiant aussi).
        
        Bref, quand tu ne connais pas, le répertoire /debian est juste le plus long à comprendre des formats, c'est pour les initiés, les "vrais". Ca n'empèche pas le reste (le côté communautaire tout ça) de faire que c'est utilisé, mais est-ce une raison pour faire 36 outils qui font la même chose? Est-ce une raison pour ne jamais vouloir enendre les critiques, et/ou regarder les autres et prendre ce qu'il y a de bien chez eux?
        
        PS : j'utilise OBS, qui essaye d'unifier les compilations, et pas une personne à fond dans une distro au point de ne pas regarder les autres, donc j'ai un regard d'une personne qui n'aime pas que faire un truc simple soit compliqué, et que ce soit "compatible" avec les autres. Et qu'on m'impose de mettre /debian à la racine pour que ça marche a le don de me gonfler.
        
        [^] # Re: Mouaif
        
        Posté par barmic le 09 septembre 2014 à 15:17. Évalué à 4.
        
        Je suis pas forcément motivé pour répondre point par point […] baratin sur les systèmes de fichiers et comme quoi ça prend de la place
        
        Pas motivé pour répondre, mais tu te fais toutes les mouches du quartier, toi ! Pour info c'est bien pire parce qu'il suffirait de 4bits pour coder cette information… C'est risible de voir ce genre d'argument (on pourra te répondre que c'est un fichier qui ne bouge pas donc dans ton VCS il a quasiment un poids nul). Je t'ai vu troller mieux que ça.
        
        je pense à comment je dois gérer le bousin avec OBS, et en plus OBS m'oblige à mettre à jour à la mano le MD5 sinon il rale si je laisse vide, bref vraiment pas pratique en automatisation, du moins comme OBS doit le gérer par rapport à RPM ou Arch
        
        Et donc c'est la faute de dpkg ? Je ne connais pas ta problématique, mais là on parle de l'intégration de 2 choses pour jeter la faute sur l'un des 2 il faut faire un peu plus que dire que tu dois modifier à la main un fichier.
        
        Et si tu n'as pas suivi[…]
        
        Il a pas dis que c'était parfait il s'est juste demandé pourquoi t'es pas content que ce soit plusieurs fichiers et pas qu'un comme tu le ressasse depuis tout à l'heure avec le .spec.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Mouaif
        
        Posté par Mildred (site web personnel) le 10 septembre 2014 à 10:12. Évalué à 5.
        
        – en quoi avoir tout dans un seul fichier est plus simple que dans des fichiers séparés ? Pour un informaticien confirmé, il me semble que c'est pas vraiment en problème mais bon.
        
        C'est un avis personnel, mais je trouve ça beaucoup plus simple: un seul buffer dans ton éditeur de texte, un seule commande dans ton shell pour ouvrir ce fichier, tout est visible sur un seul écran en un coup d'œuil. Mais ça reste très personnel.
    - [^] # Re: Mouaif
      
      Posté par Michaël (site web personnel) le 09 septembre 2014 à 10:19. Évalué à 7. Dernière modification le 09 septembre 2014 à 10:20.
      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.
      - [^] # Re: Mouaif
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 10:33. Évalué à 5.
        
        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).
        
        [^] # Re: Mouaif
        
        Posté par Michaël (site web personnel) le 27 octobre 2014 à 11:06. Évalué à 2.
        
        Et sinon, il ne faut pas hésiter à demander sur le salon IRC qui va bien (#debian-mentors sur OFTC).
        
        Pas facile d'accès…
        
        (11:04:09) You have been kicked by ChanServ: (Invite only channel)
    - [^] # Re: Mouaif
      
      Posté par Zarmakuizz (site web personnel) le 09 septembre 2014 à 10:25. Évalué à 1. Dernière modification le 09 septembre 2014 à 10:27.
      
      EDIT : grillé.
      
      Maintenant, je soupçonne que cela permette moins choses en contrepartie, comme l'indication formelle des licences utilisées
      
      https://guide.macports.org/#development.examples
      
      license GPL
      
      On parle d'essence ?
      
      l'ajout de patchs spécifiques annotés
      
      Ce n'est pas à ça que sert le changelog du projet ?
      
      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.
      
      le suivi des versions du logiciel amont et des révisions de l'empaquetage
      
      Même lien :
      
      version 1.2.23
      
      Et bien !
      
      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
      
      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 ?
      
      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. De ce que je comprends, le développeur doit dire comment il faut scinder son projet pour que les mainteneurs puissent changer 1 gros package en plusieurs petits. Plutôt que d'ajouter de la complexité à un format pour un problème humain (le développeur a préféré tout foutre ensemble au lieu de créer un paquet principal + un paquet lib), on pourrait simplement… dire par mail ou même dans la doc "écoute, on voit que ton dossier lib a l'air épais, tu devrais le séparer dans son propre paquet, vu que ton code est libre ça pourra profiter aux autres" pour le développeur qui fait son paquet.
      
      Alors certes, il y a une raison d'être, mais ces raisons d'être sont-elles encore pertinentes ? Un gros nettoyage pourrait être fait, mais quand on parle de fonctionnalités, on adore tout garder, même quand on parle de simplifier le code.
      
      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
      - [^] # Re: Mouaif
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 10:47. Évalué à 7. Dernière modification le 09 septembre 2014 à 10:50.
        
        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.
        
        [^] # Re: Mouaif
        
        Posté par Zenitram (site web personnel) le 09 septembre 2014 à 10:53. Évalué à 2. Dernière modification le 09 septembre 2014 à 10:53.
        
        Pour info, le fichier en question c'est debian/watch, utilisé par l'outil uscan (upstream scan).
        
        Et ça aurait été tellement compliqué voire impossibe que uscan ouvre le fichier "central" et lise la ligne qui va bien…
        
        Tu démontres que Debian fait de belles choses, pas qu'il faut un répertoire /debian avec plein de fichiers pour le faire.
        
        Ce que tu dis toujours, c'est que tu sais démarrer une voiture, pas pourquoi toi tu as obligatoirement besoin d'une manivelle à tourner de toutes tes forces pour le faire quand les autres ont un simple bouton à appuyer.
        
        Ça tombe bien, dans Debian ils ont été séparés en deux paquets.
        
        un .spec (rpm), dans ce que je connais, permet la même chose, et donc?
        tu démontres que… (Refrain)
        
        [^] # Re: Mouaif
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 11:05. Évalué à -1.
        
        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.
        
        [^] # Re: Mouaif
        
        Posté par barmic le 09 septembre 2014 à 11:11. Évalué à 6.
        
        Quel fichier « central » ?
        
        Il parle d'un cat debian/* > debian.pkg.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Mouaif
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 11:15. Évalué à 1. Dernière modification le 09 septembre 2014 à 11:17.
        
        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.
        
        [^] # Re: Mouaif
        
        Posté par eingousef le 09 septembre 2014 à 12:04. Évalué à 5.
        
        Peut-être que quand on commence à écrire des outils qui écrivent ou qui lisent ces infos automatiquement, c'est plus simple d'avoir des fichiers séparés qu'un seul gros fichier ?
        
        Enfin moi je m'en fous, nano debian/* et quand un fichier est déjà rempli correctement je passe au suivant, ça prend pas trois plombes.
        
        *splash!*
        
        [^] # Re: Mouaif
        
        Posté par Zenitram (site web personnel) le 09 septembre 2014 à 11:18. Évalué à 4. Dernière modification le 09 septembre 2014 à 11:19.
        
        rajoute que ce répertoire doit obligatoirement se trouver à la racine lors de la "compilation", ou alors je n'ai pas trouvé comment lui dire qu'il est ailleurs (j'utilise OBS, et si je met pas dans le tar.gz "upstream", c'est mort. D'ailleurs OBS a l'air de subir la politique de Debian, impossible de lui faire avaler un tar.bz2, question rigidité… :( )
        
        [^] # Re: Mouaif
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 11:25. Évalué à 0.
        
        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.
        
        [^] # Re: Mouaif
        
        Posté par Zenitram (site web personnel) le 09 septembre 2014 à 11:15. Évalué à 2.
        
        Quel fichier « central » ?
        
        OK, en gros tu n'as pas compris et/ou refuse de comprendre la critique, et tape toujours à côté sans parler de ce qui est critiqué (tu parles de fonctionnalités la où tout le monde parle d'implémentation inutilement complexe de la fonctionnalité), super-pratique pour la discussion.
        
        J'ai pourtant bien donné un exemple de la vraie vie, pour te donner une idée de ce que tu racontes, mais rien à faire, il vaut mieux aviter de chercher à comprendre la critique et répondre à côté pour ne pas voir le problème.
        
        Pour répondre à la question : par exemple, un .spec (ou tout autre fichier de config des autres distros) en dehors du package upstream?
        
        mais pas dans des trucs volontairement très simples,
        
        Ce que tu aimes, c'est dire que complexité rime avec fonctionnalités.
        Désolé, d'autres savent faire des choses simples iso-fonctionnelles avec ta complexité adorée, ne t'en déplaise.
        Pourquoi faire simple quand on peut faire compliqué?
        
        [^] # Re: Mouaif
        
        Posté par Spyhawk le 09 septembre 2014 à 11:27. Évalué à 4.
        
        Pourquoi faire simple quand on peut faire compliqué?
        
        Parce que Debian, comme cité plus haut.
        
        [^] # Re: Mouaif
        
        Posté par Moonz le 09 septembre 2014 à 12:14. Évalué à 4.
        
        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.
        
        Je connais pas les ports mais c’est possible avec les PKGBUILD, qu’on aura pourtant du mal à ne pas classer dans la catégorie « volontairement très simple »
        
        [^] # Re: Mouaif
        
        Posté par Mildred (site web personnel) le 10 septembre 2014 à 10:21. Évalué à 4.
        
        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.
        
        Si ces patches étaient au contraire intégrés en amont, est-ce que cela ne simplifirait pas le travail de tout le monde ?
        
        upstream qui voudrait intégrer son application dans une autre distribution respectant FHS a la lettre, ou avec le même multiarch que debian
        
        debian qui évite de porter ses changements de version en version et s'évite du travail de maintenance
        
        [^] # Re: Mouaif
        
        Posté par Sufflope (site web personnel) le 10 septembre 2014 à 20:45. Évalué à 2.
        
        A mon avis (je crois me souvenir qu'il avait été plus explicite à ce sujet en une autre occasion) quand Tanguy parle de maintenir non-upstream des patchs "de bon sens" (comme respecter la FHS) au lieu de les contribuer, c'est quand upstream a justement refusé d'incorporer ces patchs (pour tout un tas de raisons bonnes ou mauvaises selon le point de vue de chacun).
        
        [^] # Re: Mouaif
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 11 septembre 2014 à 11:04. Évalué à 10.
        
        Pas forcément, il y a a vraiment des trucs que je n'envoie pas du tout aux développeurs amont parce que je sais qu'ils le refuseront, et à juste titre, donc ce ne serait que les ennuyer pour rien.
        
        Le plus bel exemple que j'aie de cela, c'est DokuWiki, un moteur de wiki, qui, comme souvent pour les logiciels Web, intègre des bibliothèques externes telles que GeSHi, jQuery ou encore SimplePie. C'est utile pour les gens qui installent ce logiciel à la main sur leur serveur Web, mais dans le cadre de la distribution Debian, c'est mal, parce que ça alourdit inutilement le système et que ça complique la maintenance de sécurité. Donc, dans le paquet Debian de DokuWiki, j'ai ce genre de patch :
        
        Author: Tanguy Ortolo <tanguy plusse debian chez ortolo point, con ! eu> Description: Use packaged version of jQuery instead of an embedded one Forwarded: not-needed Last-Update: 2012-01-02 Index: dokuwiki/lib/exe/js.php =================================================================== --- dokuwiki.orig/lib/exe/js.php 2014-06-08 16:11:35.544575705 +0200 +++ dokuwiki/lib/exe/js.php 2014-06-08 16:11:35.532575542 +0200 @@ -40,9 +40,9 @@ // array of core files $files = array( - DOKU_INC."lib/scripts/jquery/jquery$min.js", - DOKU_INC.'lib/scripts/jquery/jquery.cookie.js', - DOKU_INC."lib/scripts/jquery/jquery-ui$min.js", + "/usr/share/javascript/jquery/jquery$min.js", + '/usr/share/javascript/jquery-cookie/jquery.cookie.js', + "/usr/share/javascript/jquery-ui/jquery-ui$min.js", DOKU_INC."lib/scripts/jquery/jquery-migrate$min.js", DOKU_INC.'inc/lang/'.$conf['lang'].'/jquery.ui.datepicker.js', DOKU_INC."lib/scripts/fileuploader.js",
        
        Ce patch donc, est spécifique à Debian, d'où le champ d'en-tête Forwarded: not-needed. Les développeurs amont ne l'intègreront pas, parce que d'une part ce n'est pas utile pour eux et pour leurs utilisateurs directs, mais qu'en plus ça casserait franchement le logiciel, à moins d'être sous Debian ou une autre distro fournissant jQuery au même endroit.
        
        [^] # Re: Mouaif
        
        Posté par Romeo le 11 septembre 2014 à 12:17. Évalué à 2.
        
        Donc tu forces l'usage d'une version interne de jquery en ne sachant pas si elle est compatible avec celle du soft ?
        
        [^] # Re: Mouaif
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 11 septembre 2014 à 14:14. Évalué à 10.
        
        Oui en effet, je force l'usage d'une version de jQuery dont je sais qu'elle reçoit des mises à jour de sécurité, c'est bien ça.
        
        [^] # Re: Mouaif
        
        Posté par groumly le 13 septembre 2014 à 08:00. Évalué à 4.
        
        Et, heu, dokuwiki, une fois patche a la truelle comme tu viens de le faire, tu le teste aussi bien que openssl a ete teste?
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Mouaif
        
        Posté par Antoine le 13 septembre 2014 à 12:34. Évalué à -2.
        
        C'est vrai que la mentalité de certains packageurs semble être "c'est bon, le paquet compile, j'ai fini mon boulot".
        
        [^] # Re: Mouaif
        
        Posté par Romeo le 13 septembre 2014 à 19:04. Évalué à 4.
        
        Ok mais ça veut dire que tout les packageurs de debian, doivent connaitre toutes les incompatibilités induite par les mises à jours de jquery et tout les usages qui en sont fait par tout les logiciels qui package…
        
        [^] # Re: Mouaif
        
        Posté par claudex le 14 septembre 2014 à 10:40. Évalué à 5.
        
        Ce n'est pas spécifique à jquery, c'est valable pour chaque projet qui inclut des lib d'un autre et où Debian fait de boulot de rendre ça propre.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Mouaif
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 11 septembre 2014 à 11:14. Évalué à 9.
        
        Et comme exemple de patch envoyé aux développeurs amont mais conservé pendant longtemps dans Debian, il y avait à une époque un bug dans Brasero, un logiciel de gravure de disques, qui faisait échouer une bonne partie des gravures de disques audio. Ce bug venait de la génération de feuilles CUE invalides, avec des index temporels avec un nombre de jiffies — soixantièmes de secondes — qui pouvait être de 60, alors qu'il aurait dû être de 0 sur la seconde d'après.
        
        J'avais donc rédigé un patch assez simple pour corriger cela, qui avait évidemment été appliqué dans Debian, par moi-même d'ailleurs, sous la forme de ce qu'on appelle un NMU, non maintainer upload, c'est à dire un envoi de nouvelle version de paquet par quelqu'un qui n'est pas le mainteneur officiel du paquet en question. Puis transmis le bug aux développeurs amont, qui avaient mis deux ou trois ans avant de l'intégrer : pendant ce temps, Brasero était bogué pour la création de disques audio, partout sauf dans Debian où ce patch était resté jusqu'à ce qu'ils l'aient finalement intégré…
        
        [^] # Re: Mouaif
        
        Posté par groumly le 13 septembre 2014 à 08:02. Évalué à 5.
        
        Oui, on peut aussi parler d'openssl, ou le patch est reste nmu des annees jusqu'a ce que upstream l'integ, ah, heu, non en fait.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
      - [^] # Re: Mouaif
        
        Posté par kupka le 12 septembre 2014 à 14:16. Évalué à 9.
        
        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.
        
        Oui, c'est moche ces gens qui modifient des logiciels libres et publient leur modifications.
# Et encore...

Posté par devnewton 🍺 (site web personnel) le 08 septembre 2014 à 23:45. Évalué à 10.

J'ai l'impression que tu packages des logiciels écrit en C avec un Makefile. Si tu as comme moi un langage et un outil de construction exotiques (java et maven), tu vas tourner en bourrique avant de comprendre que personne chez debian ne s'intéresse aux plateformes de développements utilisées uniquement par 3 geeks dans un garage.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
- [^] # Re: Et encore...
  
  Posté par Michaël (site web personnel) le 09 septembre 2014 à 00:00. Évalué à 3. Dernière modification le 09 septembre 2014 à 00:01.
  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>
  - [^] # Re: Et encore...
    
    Posté par BAud (site web personnel) le 09 septembre 2014 à 00:42. Évalué à 2.
    
    Peut-être que je vais en faire une version “dépêche” pour LinuxFR lorsque j'aurais packagé ça dans Debian.
    
    ce serait peut-être bien de commencer avant dans l'espace de rédaction ;-) cf. http://linuxfr.org/redaction si ça se trouve ce sera traduit avant que tu ne finisses ton paquet :D
  - [^] # Re: Et encore...
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 09:36. Évalué à 9.
    
    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.
    - [^] # Re: Et encore...
      
      Posté par Michaël (site web personnel) le 09 septembre 2014 à 10:54. Évalué à 2.
      C'est une proposition fantastique et très sympa! J'ai préparé une branche debian avec mon travail préliminaire:
      
      https://bitbucket.org/michipili/bsdowl/branch/debian
      
      Si j'ai bien compris le workflow typique consiste à garder cette branche à part et à y merger régulièrement master à chaque nouvelle version.
      
      Il y a mon adresse mail toutes les deux lignes dans les sources, n'hésite pas à l'utiliser!
      - [^] # Re: Et encore...
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 11:11. Évalué à 4. Dernière modification le 09 septembre 2014 à 11:13.
        
        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é) !
        
        [^] # Re: Et encore...
        
        Posté par Michaël (site web personnel) le 09 septembre 2014 à 11:34. Évalué à 2.
        
        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.
        
        Chouette. Au cas où tu serais passé à côté, j'ai écrit une introduction pour l'utilisation de bsdpwl dans ce cas:
        
        https://bitbucket.org/michipili/bsdowl/wiki/ProduceLaTeXDocuments
        
        Et les taballs sont signés en plus ! La classe[…]!
        
        Et en plus la production de ces tarballs et des signatures est réaliséé automatiquement par bsdowl — bmake prepublish dans le dossier du projet. Bref, c'est vraiment la classe!
# Résumons

Posté par Zenitram (site web personnel) le 09 septembre 2014 à 09:11. Évalué à 10.

Comme d'habitude : une personne expose ses problèmes pratiques suite à sa mésaventure lors de la découverte de certains outils, en bonus cette personne connait des outils concurrent donc peut bien comparer, et les defenseurs conservateurs de l'outil critiqué vont lui expliquer que tout va bien chez eux, en faisant l'autruche sur les problèmes, en les rejetant, en faisant comme si ils n'existaient pas, à coup de commandes magiques sorties de nul part.

Toujours aussi beau!
- [^] # Re: Résumons
  
  Posté par octane le 09 septembre 2014 à 09:32. Évalué à 9.
  
  Tu vas te faire moinsser sévère, mais tu as malheureusement raison.
  - [^] # Re: Résumons
    
    Posté par Zenitram (site web personnel) le 09 septembre 2014 à 10:25. Évalué à -3. Dernière modification le 09 septembre 2014 à 10:26.
    
    Comme quoi, on ne sait jamais à l'avance (en écrivant mon commentaire, je pensais moi aussi au moinsage, et me voila en teritoire grandement positif, sans même de réaction négative, ça me fait tout drôle, je n'ai pas l'habitude de ne pas cliver).
    De quoi donner espoir, peut-être qu'à force de démontrer qu'il y a un problème, de le répéter encore et encore, le problème va être compris, et ensuite il y aura peut-être une réflexion sur comment proposer mieux… On a bien eu systemd qui a réussi montrer qu'il pouvait être plus simple que l'existant pour le mainteneur et les réunir tous, peut-être qu'un jour on aura un système de création commun et simple de package!
- [^] # Re: Résumons
  
  Posté par Adrien le 09 septembre 2014 à 14:10. Évalué à -1.
  
  Si j'ai bien compris, selon toi les outils Debian sont totalement à la ramasse, complètement nul face la concurrence.
  
  Comment expliques-tu que Debian est souvent une base pour la création d'une nouvelle distribution, si les outils et procédures sont si nules ?
  - [^] # Re: Résumons
    
    Posté par octane le 09 septembre 2014 à 14:23. Évalué à 8.
    
    Debian est souvent une base pour la création d'une nouvelle distribution, si les outils et procédures sont si nules ?
    
    Si j'avais à choisir, ce serait plus pour la pérennité de la distro et le nombre de mainteneurs que la qualité de leurs outils.
    - [^] # Re: Résumons
      
      Posté par zebra3 le 23 septembre 2014 à 15:59. Évalué à 2.
      
      Comment pourrait-elle être aussi pérenne avec des outils pourris ?
      
      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
  - [^] # Re: Résumons
    
    Posté par kna le 09 septembre 2014 à 16:47. Évalué à 2.
    
    Si le mainteneur se retrouve à se battre avec des outils complexe pour créer un paquet, suivre toutes les règles pour que son paquet soit accepté ; pour l'utilisateur en contrepartie, il est assuré d'avoir un paquet bien intégré comme il faut à la distrib, avec tout ce qu'il attend d'un tel paquet. Il n'as pas un truc qui juste marche mais est empaqueté comme un goret avec des fichiers se retrouvant à des endroits improbables ou un paquet sans page man.
    - [^] # Re: Résumons
      
      Posté par Anonyme le 09 septembre 2014 à 17:45. Évalué à 5.
      
      Si le mainteneur se retrouve à se battre avec des outils complexe pour créer un paquet, suivre toutes les règles pour que son paquet soit accepté ; pour l'utilisateur en contrepartie, il est assuré d'avoir un paquet bien intégré comme il faut à la distrib, avec tout ce qu'il attend d'un tel paquet.
      
      Devoir se battre avec les outils n'assure pas que les choses seront mieux faites. Sinon il suffirait d'imposer aux gens d'écrire tous leurs programmes en assembleur.
# Et sous slackware?

Posté par octane le 09 septembre 2014 à 09:38. Évalué à 10.

Sous slackware, un package, c'est un tgz contenant le nom et la version du soft.
Le build, c'est un script shell qui contient le slackbuild, par exemple pour netcat:
http://slackbuilds.org/slackbuilds/14.1/network/netcat/netcat.SlackBuild

Ca se modifie/hack à la main super facilement, les paquets binaires se modifient super facilement, on détar modifie et retar ensuite.
Comme on dit, c'est simple, ça marche.
- [^] # Re: Et sous slackware?
  
  Posté par zul (site web personnel) le 09 septembre 2014 à 10:35. Évalué à 3.
  
  Non le shell c'est nul et compliqué. Il faut le remplacer par des unit systemd (quoi on est pas vendredi :D).
- [^] # Re: Et sous slackware?
  
  Posté par David Carlier le 10 septembre 2014 à 06:58. Évalué à 2.
  
  Slackware !! bien plus de 10 ans que je n'ai pas fourré mon nez dedans. Intéressant c'est plus simple que je le pensais, merci ça me servira peut être au cas où !
# C'est l'histoire et la démocratie

Posté par benoar le 09 septembre 2014 à 15:59. Évalué à 10.

Je suis justement en train d'écrire depuis plusieurs mois une doc sur la création de paquetage pour Debian, basé sur les autotools. C'est clair que ça n'est pas simple. Je vois deux principales raisons à ça : l'historique de Debian, qui est quand même une des plus anciennes distros, et le fait que Debian avant tout une communauté de gens qui s'accordent selon des principes démocratiques avant d'être une solution technique.

Le premier point doit être la raison des fichiers un peu en vrac (car je ne connais pas leur histoire exacte) : c'est clair que ça n'est pas « propre » comme le voudraient certains esthètes, mais c'est de toute façon géré automatiquement aujourd'hui pour la plupart. Les fichiers essentiels à connaître son décrits ici : https://www.debian.org/doc/manuals/maint-guide/dreq.fr.html. D'ailleurs, c'est la doc officielle du mainteneur, et je la trouve plutôt bien faite, en plus d'être traduite en français : https://www.debian.org/doc/manuals/maint-guide/index.fr.html. Le wiki, c'est vraiment une source pas terrible selon moi (oui, je suis en train de tendre le bâton pour me faire battre).

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 (mais pour cause de rétro-compatibilité, on peut faire soit l'un soit l'autre) ; le changelog c'est parce qu'historiquement, on n'avait pas de VCS, et puis il est utilisé par plein d'outils pour en extraire des informations (comme la version : ainsi, le fichier contrôle qui définit l'identité du paquet change peu) ; et le fichier rules est séparé du control car celui-ci n'est pas descriptif, mais est un ensemble de commandes. On pourrait essayer d'en réunir certains, mais je ne vois pas de raisons très convaincantes.

La rétro-compatibilité, c'est très important, même si c'est chiant : ce sont souvent les empaqueteurs « jeunes » qui vont râler sur tous ces archaïsmes qui viennent les embêter. Mais avec l'âge, on apprend que certains de ceux-ci (pas tous, hein), et le principe de rétro-compatibilité, sont vraiment très importants.

Ce qui est aussi très important dans Debian, c'est la conformance à ses standards sur la liberté du code : c'est une des raisons de la normalisation du noms des paquets sources, car ceux-ci peuvent aussi être retravaillés s'ils contiennent des morceaux qui ne respectent pas la charte (les sources sont appelées dfsg-free pour “Debian Free Software guidelines”-free). C'est un point très important également pour la distribution : Debian possède un réseau de distribution assez gigantesque et pourtant gratuit pour l'utilisateur, car les personnes (les ftpmaster) qui le font ont confiance dans la légalité de ce que fait le projet.

La deuxième raison est celle qui fait qu'il y a 40 manière de faire chaque chose dans Debian : beaucoup de monde a une idée différente de comment « bien » faire les choses, et du coup, soit on s'accorde sur une méthode commune (genre la gestion unifée des patchs dans le format 3.0, lancée par Raphaël Hertzog qui traîne ici), soit on trouve une manière de faire cohabiter « pacifiquement » les différentes méthodes (comme le fait que les mainteneurs ont des préférences de VCS différentes, même si j'ai l'impression que git domine ; bon, c'est justement un peu ce qu'a permis le passage au format 3.0). C'est plus compliqué quand les gens n'arrivent pas à s'accorder, mais on ne peut pas (ou rarement) avoir recours à des méthodes autoritaires pour décider d'une seule et unique manière de faire quand on est une communauté régie par une constitution. Ça ne va pas plaire aux « pragmatiques » du coin, mais moi je trouve ça très pragmatique au contraire.

C'est cette vision démocratique qui fait aussi que l'historique a l'air parfois un peu inconsistant : le projet évolue au fur et à mesure de sa vie, et les standards changent d'une époque à l'autre. Malgré tout ça, je trouve que le projet Debian se porte plutôt bien, et est reconnu pour la qualité des ses paquets, à défaut de sa célérité d'empaquetage. Je pense que c'est dû très largement à sa manière de voir le but du projet comme un objet social et politique plutôt que de se concentrer sur la partie technique (même si elle est pourtant très reconnue).

Les méthodes d'empaquetage pour d'autres projets ont beau être techniquement « supérieure », je ne suis pas sûr que ça tienne complètement sur le long terme sans objectif moins technique : j'ai souvenir que le standard il y a dix ans sous MacOS X c'était fink. Je suppose que ça a changé vu que je n'entends plus parler que de MacPorts les quelques fois où je rencontre ce genre de packaging (et à l'époque MacPorts n'était pas terrible). Un autre « mauvais » exemple est OpenWrt : je trouve le système de packaging vraiment génial, mais la communauté derrière est assez désordonnée et mal organisée, ce qui fait que le projet est toujours un peu vacillant (et pourtant j'adore ce qu'ils font). Bref, se concentrer sur la technique, c'est oublier un aspect très important du logiciel libre.
- [^] # Re: C'est l'histoire et la démocratie
  
  Posté par Anonyme le 09 septembre 2014 à 16:21. Évalué à 8.
  
  La rétro-compatibilité, c'est très important, même si c'est chiant : ce sont souvent les empaqueteurs « jeunes » qui vont râler sur tous ces archaïsmes qui viennent les embêter. Mais avec l'âge, on apprend que certains de ceux-ci (pas tous, hein), et le principe de rétro-compatibilité, sont vraiment très importants.
  
  Ou pas. La rétro-compatibilité ca a quand meme un cout très important en complexité.
  
  Moi je suis plutot pour avoir le minimum de rétro-compatibilité, quand c'est possible. Quand on change quelquechose, on garde eventuellement une rétro-compatibilité pendant 1 ou 2 releases, on convertit tout le plus rapidement possible, et on se débarrasse de la rétro-compatilité des que c'est fait. Ca permet de garder les choses simples.
  
  C'est d'ailleurs la meme raison pour laquelle les dev du noyau linux aiment avoir tous les drivers inclus directement dans l'arbre des sources du noyau: en cas de changement dans l'api interne, on modifie directement tous les drivers qui utilisent cette api, et il n'y a pas besoin de garder une compatibilité avec l'ancienne api.
  - [^] # Re: C'est l'histoire et la démocratie
    
    Posté par benoar le 10 septembre 2014 à 12:05. Évalué à 3.
    
    Moi je suis plutot pour avoir le minimum de rétro-compatibilité, quand c'est possible. Quand on change quelquechose, on garde eventuellement une rétro-compatibilité pendant 1 ou 2 releases, on convertit tout le plus rapidement possible, et on se débarrasse de la rétro-compatilité des que c'est fait. Ca permet de garder les choses simples.
    
    Et bien sache que certains y voient exactement l'inverse ! Et trouvent que c'est changer les choses qui est compliqué. Quand tu gardes des interfaces sur le long terme, ça évite d'avoir à retravailler les softs tous les quatre matins.
    
    C'est d'ailleurs la meme raison pour laquelle les dev du noyau linux aiment avoir tous les drivers inclus directement dans l'arbre des sources du noyau: en cas de changement dans l'api interne, on modifie directement tous les drivers qui utilisent cette api, et il n'y a pas besoin de garder une compatibilité avec l'ancienne api.
    
    Oui, effectivement : le tout est de savoir où placer les limites de stabilité. Note que l'ABI des syscall de Linux (oui, même le format binaire !) est plutôt assez stable, c'est ce qui permet par exemple à Docker de bien marcher (ça tourne sur tous les noyaux supérieurs à 3.X (j'ai oublié le X) sans se poser de questions), car un kernel se doit d'être une interface stable avec les applications utilisateur. Par contre, pour les interfaces driver-kernel, on estime que la stabilité est moins importante, car le support du matériel n'est pas considéré bon quand il est effectué en dehors de la branche principale. Oui, ce sont des jugements de valeur, les devs kernel ont tranché, et globalement ça marche plutôt pas mal comme ça.
    
    Pour le packaging, pareil, le projet Debian a choisi les frontières de stabilité : un paquet source doit être dans un format qui change peu souvent car les outils de gestion de ces paquets sont complexes, et que faire évoluer l'ensemble des paquets de l'archive Debian est une gageure. Pour le format binaire, c'est encore « pire » : il faut potentiellement que les paquets binaires soient installables par des versions diverses et variées de dpkg et apt. Par contre, la manière pour les développeurs de gérer leurs modifications est en changement constant. Forcément, ce côté n'est pas vu par les utilisateurs : eux ne voient que le côté plutôt fixe. Et — comble de l'ironie — on a parfois des devs qui se plaignent que ça change trop pour les différentes possibilités de gestion du packaging !
    
    Perso, la complexité n'est pas mauvaise quand elle est « simplement » dû au manque de documentation sur certaines procédures : c'est un classique du libre, ça se « corrige ». Je trouve que techniquement, les contraintes de rétro-compatibilité sont plutôt très supportables. Mais c'est clair que oui, niveau documentation, il y aurait encore des efforts à faire, même si la doc officielle est un bon début, même si elle est certes longue : non, on ne peut pas se lancer en une heure à faire un package Debian, ça demande (malheureusement ou heureusement, si on s'oriente du point de vue qualité) un peu plus d'effort.
    - [^] # Re: C'est l'histoire et la démocratie
      
      Posté par barmic le 10 septembre 2014 à 14:53. Évalué à 5.
      
      Quand tu gardes des interfaces sur le long terme, ça évite d'avoir à retravailler les softs tous les quatre matins.
      
      C'est la parabole de la cathédrale et du bazar. "Éviter de toucher à du code", c'est se payer une dette technique.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: C'est l'histoire et la démocratie
        
        Posté par benoar le 10 septembre 2014 à 17:49. Évalué à 2.
        
        "Éviter de toucher à du code", c'est se payer une dette technique.
        
        Pas forcément, comme je disais avant à propos de « pas tous » les archaïsmes à garder. Ça dépend d'où tu as placé tes interfaces, de comment elles ont été définies, etc. On utilise tous des parties de codes qui n'ont pas bougé d'un iota depuis des lustres (les tty, le principe du tout fichier, le HTML, l'ISA x86, etc) qui sont pourtant des choses qui sont plutôt pas mal aujourd'hui. Et le fait que Debian soit toujours si « populaire » (d'une certaine manière) me fait dire que c'est une distribution qui a plutôt fait des bons choix. Le bazar, ça ne veut pas dire réiventer la roue tous les quatre matins, hein, ça n'empêche pas d'avoir un peu de stabilité sur certains points — et heureusement.
        
        [^] # Re: C'est l'histoire et la démocratie
        
        Posté par barmic le 10 septembre 2014 à 23:12. Évalué à 4.
        
        les tty
        
        Ça a au moins était revu récemment pour virer le BKL
        
        le principe du tout fichier
        
        C'est un principe, pas du code, mais bon c'est un principe qui a évolué depuis unix/multics, la plus grosse nouveauté viens probablement des systèmes de fichiers virtuels qui sont utilisé dans linux pour /proc et /sys, plus récemment pour les cgroup. fuse est pleins d'exemples pour ça. Les api pour accéder aux fichiers ont aussi pas mal changées principalement pour pouvoir être asynchrones. Hurd apporté les translators, mais au final ça peut se gérer via un système de fichier virtuel (même si c'est probablement plus simple avec hurd).
        
        le HTML
        
        HTML5 ça ne te dis rien ? On a viré des balises, on en a jouté d'autres, tout un tas de manière de faire ont étaient dépréciées par les CSS3, on a créé le XHTML, puis on a intégré les bonnes idées de ce dernier dans HTML. C'est compatible peut être mais ça a grandement évolué.
        
        l'ISA x86
        
        Le x86 ?! Tu n'a jamais entendu parler des i{3,4,5,6}86, des jeux d'instruction comme SSE, intelVT ou ceux qui ont fait parler d'eux récemment pour ajouter de l'entropie ?
        
        Tu parle principalement d'interface compatible ce qui n'a rien avoir :
        
        on peut garder l'interface tout en réécrivant totalement l'implémentation
        
        on peut garder une interface compatible tout en la faisant évoluer
        
        Ça n'a rien avoir avec « éviter de modifier du code », je n'aurais pas dis la même chose si tu avait parlé d'« éviter de modifier des interfaces ».
        
        Le bazar, ça ne veut pas dire réiventer la roue tous les quatre matins, hein, ça n'empêche pas d'avoir un peu de stabilité sur certains points — et heureusement.
        
        Le bazard c'est ne pas hésiter à modifier le code si besoin, éviter de forger les choses dans le marbre. Tu confond les interfaces et le code. Et oui debian pourrait tout à fait modifier la façon de faire sans rompre la compatibilité, c'est une question de volonté plus qu'un quelconque choix plus ou moins technique.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: C'est l'histoire et la démocratie
        
        Posté par benoar le 11 septembre 2014 à 11:16. Évalué à 3.
        
        Ça n'a rien avoir avec « éviter de modifier du code », je n'aurais pas dis la même chose si tu avait parlé d'« éviter de modifier des interfaces ».
        
        Heu… je n'ai jamais parlé d'éviter de modifier du code. Les interfaces dont j'ai parlé pour Debian n'ont peut-être pas beaucoup bougé, mais le code derrière, si, quand on en a senti le besoin (c'est à dire pas forcément partout).
        
        Le bazard c'est ne pas hésiter à modifier le code si besoin, éviter de forger les choses dans le marbre. Tu confond les interfaces et le code. Et oui debian pourrait tout à fait modifier la façon de faire sans rompre la compatibilité, c'est une question de volonté plus qu'un quelconque choix plus ou moins technique.
        
        Je pense qu'il y a une incompréhension : les choses « forgées » dans le marbre, il y en a partout dans les exemples que tu as cité (les codes du VT200, le principe de balise dans le HTML, les instructions x86 communes à tous les CPU Intel depuis les années 70), comme dans Debian. L'important est de savoir lesquelles, à quel endroit, etc. Debian a déjà modifié sa façon de faire sans rompre la compatibilité ; la preuve par exemple, le fichier indiquant le niveau de compatibilité n'a pas bougé, mais c'est justement pour pouvoir faire bouger tout le reste quand ce numéro change !
        
        Je vois mal comment tu peut me faire un homme de paille aussi gros là-dessus.
        
        [^] # Re: C'est l'histoire et la démocratie
        
        Posté par barmic le 11 septembre 2014 à 11:32. Évalué à 4.
        
        Heu… je n'ai jamais parlé d'éviter de modifier du code.
        
        Excuse-moi tu parle d'"éviter de modifier les soft". Je vois pas ce qu'on peut modifier dans un soft à part les sources. Ce que je dis c'est que ce n'est pas un argument valable.
        
        Debian a déjà modifié sa façon de faire sans rompre la compatibilité[…]
        
        Ce que tout le monde dis ici, c'est qu'ils sont loin de l'avoir fait suffisamment ou du moins pas dans le bon sens. Grosso modo Debian a modifié son format dans l'unique but de gérer des cas de plus en plus tordu et à laisser à des outils extérieur le soin de tenter de simplifier les choses. C'est pour ça qu'on se retrouve avec un format loin d'être trivial et une profusion d'outils debianhelper avec une dichotomie pas toujours heureuse (si j'ai un projet à base d'autotools dont les sources sont sur un dépôt git dois-je utiliser dh_make ou le dh pour git ?).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: C'est l'histoire et la démocratie
        
        Posté par Antoine le 12 septembre 2014 à 11:46. Évalué à 2.
        
        le principe du tout fichier
        
        Il faudrait que les fanboys Unix arrêtent de se reclamer de ce principe qui n'en est plus un depuis longtemps (par exemple : un mutex POSIX, ce n'est pas un fichier).
        
        [^] # Re: C'est l'histoire et la démocratie
        
        Posté par lasher le 15 septembre 2014 à 16:40. Évalué à 2.
        
        Je ne comprends pas bien cette remarque. Le principe du « tout fichier » c'est (à ma connaissance hein) pour tout ce qui concerne les entrées-sorties. Un mutex n'en fait pas partie (par définition il s'agit d'un objet en mémoire partagée).
- [^] # Re: C'est l'histoire et la démocratie
  
  Posté par Moonz le 09 septembre 2014 à 16:57. Évalué à 3.
  
  le principe de rétro-compatibilité, sont vraiment très importants.
  
  Pourquoi ? C’est quoi l’intérêt de pouvoir construire un package d’il y a 10 ans sur une distrib d’aujourd’hui ? En quoi est-ce tellement plus important que d’avoir un système propre et clair aujourd’hui ?
  - [^] # Re: C'est l'histoire et la démocratie
    
    Posté par Zenitram (site web personnel) le 09 septembre 2014 à 17:04. Évalué à 4. Dernière modification le 09 septembre 2014 à 17:04.
    
    Avoir une seule config pour toutes les versions de la distro, c'est quand même bien utile pour les projets qui sont la depuis le début.
    Après, vue la durée de vie d'une distro Debian (~3 ans), garder le vieilleries de plus de 3 ans est "surprenant". Et 3 ans, ça passe vite.
    - [^] # Re: C'est l'histoire et la démocratie
      
      Posté par Moonz le 09 septembre 2014 à 17:58. Évalué à 1.
      
      Tu n’as de toute façon pas une seule config pour toutes les versions de la distro vu que chez debian chaque version de la distro a une version upstream différente…
      - [^] # Re: C'est l'histoire et la démocratie
        
        Posté par Zenitram (site web personnel) le 09 septembre 2014 à 18:05. Évalué à 2.
        
        1/ Si il y a juste le numéro de version à changer (genre le projet n'a rien cassé entre les versions), c'est plus sympa qu'une prise de tête par version.
        2/ Des fois, le projet est assez mûr et la version ne change pas…
        3/ il y a des gens en dehors du repo officiel qui "compile" la même version pour toutes les versions de la distro (oui, OBS répond à un besoin des gens de s'affranchir de la version figée de la distro), et c'est donc pratique quand même
        4/ J'imagine que d'autres trouveront un 4.
- [^] # Re: C'est l'histoire et la démocratie
  
  Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 septembre 2014 à 23:27. Évalué à 5.
  
  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é !
# ici

Posté par gnumdk (site web personnel) le 09 septembre 2014 à 23:15. Évalué à 6.

Tout est résumé ici:
http://cfnarede.com.br/sites/default/files/infographic_debian-v2.1.en.png
- [^] # Re: ici
  
  Posté par Spyhawk le 09 septembre 2014 à 23:34. Évalué à 2.
  
  C'est sympa ce visual, merci pour le lien!
  
  Quelqu'un saurait expliquer pourquoi le nombre de développeurs est radicalement passé de 1500 à 1000 (-33%!) lors de la sortie d'Etch? Graphe du haut, au milieu.
  - [^] # Re: ici
    
    Posté par Spyhawk le 10 septembre 2014 à 00:04. Évalué à 3.
    
    Je me réponds à moi même: l'arrivée d'Ubuntu, et la migration massive de DD qui ont effectivement atteint l'"illumination". J'ai bon?
  - [^] # Re: ici
    
    Posté par claudex le 10 septembre 2014 à 18:36. Évalué à 3.
    
    Si je ne dis pas de bêtise, il s'agit du retrait automatique des développeurs inactifs.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: ici
  
  Posté par Zenitram (site web personnel) le 10 septembre 2014 à 07:49. Évalué à 3.
  
  Tout est résumé ici:
  
  Certes, mais pas libre, Debian lui plait au gars mais pas au point de libérer son travail ;-).
  - [^] # Re: ici
    
    Posté par BAud (site web personnel) le 10 septembre 2014 à 14:27. Évalué à 2. Dernière modification le 10 septembre 2014 à 14:29.
    moui, c'est ballot une CC-by-NC-sa d'autant que :
    - le fichier source (en svg) n'est pas à disposition non plus :/
    - il n'y a pas de licence claire sur le fichier de traduction
      
      une faute à get envolved !
      
      le tout trouvé sur la page http://cfnarede.com.br/node/2 pour ceux qui aiment lire le portugais ;-) (et c'est dispo en anglais aussi)
    - [^] # Re: ici
      
      Posté par eingousef le 11 septembre 2014 à 11:32. Évalué à 5.
      
      Et puis y'a plein d'images dedans qui sont pas libérables, à moins de recevoir l'accord de Pixar et de la Mozilla Foundation.
      
      *splash!*
- [^] # Re: ici
  
  Posté par Antoine le 12 septembre 2014 à 11:48. Évalué à 1.
  
  Amusant que la population des administrateurs de serveurs soit représentée par une bande de gars en costard.
  - [^] # Re: ici
    
    Posté par freem le 12 septembre 2014 à 13:05. Évalué à 4.
    
    Heu, non, ce ne sont pas les admin, mais les utilisateurs conservateurs, nuance. Au fil des discussions sur la ml, j'ai découvert que certains admin utilisent aussi l'unstable (en fonction des usages du serveur bien entendu).
    
    D'ailleurs, point surprenant, certains considèrent (lu sur debian-user@lists.debian.org) que la pire des versions de Debian pour un serveur, c'est testing, parce qu'elle n'à pas les MaJ de sécu de la stable, et évolue moins vite qu'unstable, et du coup ce serait plus simple pour un attaquant de péter une testing qu'une unstable ou une stable. Je doute que je restitue correctement l'argument, ça remonte à plusieurs mois en arrière, mais j'avais trouvé ça très pertinent.
    - [^] # Re: ici
      
      Posté par Antoine le 12 septembre 2014 à 13:21. Évalué à 2.
      
      Heu, non, ce ne sont pas les admin, mais les utilisateurs conservateurs, nuance.
      
      Et donc ils sont en costard ? :)
      - [^] # Re: ici
        
        Posté par freem le 12 septembre 2014 à 14:27. Évalué à 3.
        
        C'est vrai que l'auteur aurait du les représenter en queue de pie :)
    - [^] # Re: ici
      
      Posté par vv222 (site web personnel) le 13 septembre 2014 à 16:52. Évalué à 2.
      
      certains considèrent (lu sur debian-user@lists.debian.org) que la pire des versions de Debian pour un serveur, c'est testing, parce qu'elle n'à pas les MaJ de sécu de la stable, et évolue moins vite qu'unstable, et du coup ce serait plus simple pour un attaquant de péter une testing qu'une unstable ou une stable.
      
      Pour qu’un paquet soit accepté en testing il faut qu’il ait "mûri" un certain temps en unstable. Le résultat est que si une faille passe inaperçue lors du passage d’une version en unstable, et que donc celui-ci est descendu en testing, il faudra attendre que la version le corrigeant ait suivi la même procédure de passage par unstable avant de descendre en testing. Un correctif met donc plus de temps à arriver en testing qu’en unstable.
      Maintenant la situation a changé avec l’ajout de dépôts security pour la testing. mais je n’utilise pas suffisamment celle-ci pour commenter sur les changements apportés.
      
      De toutes façons la version stable est la seule recommandée pour une utilisation en production, utiliser une testing ou une unstable pour faire tourner un serveur est possible, mais nécessite d’aimer le sport.
      - [^] # Re: ici
        
        Posté par freem le 15 septembre 2014 à 16:49. Évalué à 2.
        
        De toutes façons la version stable est la seule recommandée pour une utilisation en production, utiliser une testing ou une unstable pour faire tourner un serveur est possible, mais nécessite d’aimer le sport.
        
        Officiellement, pour tous les usages, seule la stable est recommandée. Dans la pratique, à mon faible niveau, en fonction de la personne à qui je m'adresse je conseillerais parfois plutôt la testing… de là à imaginer que certains admin puissent préférer unstable pour certains usages, il n'y à pas grand chose.
        Mais bon, c'est sûr que pour suivre quelles sont les MaJ réellement pertinentes et les autres, ça ne doit pas être simple (on peut récup les changelog de Debian, certes, mais le problème est qu'il faut aussi aller consulter les logs officiels des projets puisque Debian ne les intègre pas… malheureusement. Je me demande pourquoi d'ailleurs?) vue la fréquence de MaJ.
        Ceci étant dit, ça doit quand même être moins rock'n roll qu'une distro en rolling release j'imagine? Et je ne serai pas surpris qu'il y ait des serveurs qui tournent sous arch par exemple, vue la popularité de cette distro (enfin, c'est l'impression que j'ai, qu'arch est populaire. Après, pour un serveur, je n'en ai aucune idée…)
# dpkg-buildpackage -rfakeroot, mon ami ....

Posté par David Carlier le 10 septembre 2014 à 06:53. Évalué à 9. Dernière modification le 10 septembre 2014 à 06:54.

Professionnellement faisant divers versions de paquets Linux (Debian/Ubuntu, Redhat, Gentoo) et FreeBSD, je trouve aussi que faire un .deb est plus complique (imho), penser a la retrocompatibilité comme mentionné plus haut. Le manque de cohérence de la doc est vraiment ennuyeux. Dans mon cas je dois faire le paquet pour les libs puis un autre paquet "dev", un paquet nginx (celui là il m'en a fait voir :-)) et un module apache.
J'admets que Redhat est un peu mieux de ce point de vue là (et pourtant je préfère de loin Debian en tant qu'user…), faire le même paquet nginx equivalent m'a pris deux fois moins de temps, meme si la doc a ce propos n'est pas vraiment meilleure … Juste a bien configurer le fichier spec ! Juste a m'habituer a Selinux (que je n'aime pas des masses mais le boulot c'est le boulot :-)) et a compiler avec les flags qui vont bien…De plus les meme paquets fonctionnent dans (par exemple) CentOS 5 and Centos 6 !
Gentoo m'a etonnamment surpris et honnêtement meilleur que FreeBSD de ce point de vue la, c'est un regal de faire un portage ! J'ai presque eu envie de switcher de Debian à Gentoo rien que pour ca :-) … Comme l'auteur, je suis un peu habitue a faire des ports FreeBSD et là où FreeBSD reste imbattable, c'est la cohérence de l'ensemble de la doc, un handbook sur la fabrication de port (et bien écrit qui plus est…) et roulez jeunesse.
# Quelqu'un utilise fpm ?

Posté par David Carlier le 10 septembre 2014 à 07:04. Évalué à 3.

https://github.com/jordansissel/fpm

Utilisé une fois ou deux pour construire un paquet varnish + quelques vmod … ça marche plutôt pas mal ma foi …
# C'est pas le pire ...

Posté par Sébastien Rohaut le 10 septembre 2014 à 11:15. Évalué à 0.

… Le pire c'est tenter d'écrire un "kickstart" pour un installation automatique. Simplicité enfantine sur Redhat, le parcours du combattant sous Debian (et ubuntu).
- [^] # Re: C'est pas le pire ...
  
  Posté par Prosper le 10 septembre 2014 à 16:52. Évalué à 2.
  
  J'ai pas eu plus de difficultés à déployer FAI qu'un kickstart.
  - [^] # Re: C'est pas le pire ...
    
    Posté par Kioob (site web personnel) le 10 septembre 2014 à 18:01. Évalué à 6.
    
    Ou debootstrap d'ailleurs. L'installation d'une Debian, ça s'automatise même très très bien.
    
    alf.life

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.