[F] Logiciel : packages vs bundles (ex-Mon langage est mieux que le tien) - Page 1

Ce sujet est issu d'une discussion ayant dérivé sur deux thèmes distincts. Pour vous rendre sur le sujet d'origine, suivez ce lien.

Zerosquare (./687) :
Oui, parce qu'utiliser un soft sans problème d'installation et de version, ça serait pas drôle

C'est exactement ce que j'ai avec un logiciel packagé correctement. Je cherche "kdevelop" dans Apper, je clique "Install" et "Apply", et voilà, j'ai mon EDI. Pas d'horreurs bundlés qui risquent d'entrer en conflit avec les versions système et qui ne reçoivent pas de mises à jour de sécurité (ni de mises à jour tout court). Tout est mis à jour automatiquement avec le système.

Et CodeLite n'est même pas dans les dépôts officiels de Fedora (probablement justement à cause de cette attitude: Les logiciels qui bundlent tout sont une horreur à packager parce qu'il faut passer son temps à virer tous les trucs bundlés et utiliser des dépendances à la place), donc trop compliqué à installer → poubelle.

Heureusement qu'il y a le Parti les packagers pour déterminer à ta place quel logiciel est bon pour toi !

Kevin Kofler (./693) :
C'est exactement ce que j'ai avec un logiciel packagé correctement. Je cherche "kdevelop" dans Apper, je clique "Install" et "Apply", et voilà, j'ai mon EDI.

C'est marrant, chez moi aussi (Linux Mint, mais aussi Ubuntu et Debian) il me suffit de chercher KDevelop, cliquer sur "Install", et voilà !
Et je ne vois pas ce que cela a de différent avec le fait de rechercher CodeLite, cliquer sur "Install", et voilà !
Peut-être simplement le fait que si Debian propose CodeLite et pas Fedora, c'est Debian qui a un problème.

Kevin Kofler (./693) :
Pas d'horreurs bundlés qui risquent d'entrer en conflit avec les versions système et qui ne reçoivent pas de mises à jour de sécurité (ni de mises à jour tout court). Tout est mis à jour automatiquement avec le système.

Je dois me tromper sur mon système alors. J'avais l'illusion de penser que quand j'installais un logiciel avec ses dépendances, lesdites dépendances suivaient également une mise à jour automatique.

Kevin Kofler (./693) :
donc trop compliqué à installer → poubelle

Oui euh alors là...
Primo, quand je veux installer KDevelop, il faut que j'installe QUOI si je veux l'essayer sans encore savoir ce que je veux ?
Non parce que CodeLite, en deux install c'est fait.



Et puis quand on parle du bon packaging, c'est oublier un peu vite la dépendance au bureau utilisé.
Fichier joint :
Fichier joint :

Meowcat> c'est pas vraiment du packaging. Le fait est que Kdevelop est une application KDE, et que pour cette raison, si tu n'utilises pas un environnement KDE ça l'exclue pratiquement d'office. Un peu comme il ne te viendrait pas à l'idée d'utiliser Kate ou Kmail dans un environnement Gnome. Pour cette raison, ce n'est pas une vraie dépendance mais plutôt une contrainte : Kdevelop, c'est pour KDE.
Et donc la question Kdevelop ou Codelite ne peut se poser que si tu utilises KDE, si ce n'est pas le cas, c'est forcément Codelite.


Le packaging proprement dit, c'est un détail et je vois même pas pourquoi on en parle. Ça affecte les 2 minutes de l'install, alors que ce qui compte c'est la qualité du logiciel dans son usage, son intégration, ses fonctionnalités, son ergonomie, à la rigueur le support. Le seul post vraiment utile en fait c'était celui de Folco (./681).
D'aillers je connais pas codelite, mais l'avis de Folco m'a donné envie de l'essayer la prochaine fois que je fais autre chose que du python/js (ouais, ça fait de la full stack web ces temps ci).

Un tour de quelques secondes dans l'interface de packaging Debian, ou un tour de moins d'une minute impliquant une quarantaine de keypresses et environ 5 clics dans sa version en ligne consultable sans avoir Debian (https://packages.debian.org/codelite -> https://packages.debian.org/sid/codelite + https://packages.debian.org/sid/codelite-plugins -> https://packages.debian.org/sid/amd64/codelite/filelist + https://packages.debian.org/sid/amd64/codelite-plugins/filelist ) nous indique que...

[code]# apt-file show codelite codelite-plugins
[...]
[/code]

... le travail de de-bundling est déjà effectué par Debian.
L'examen, toujours en moins d'une minute, des infos permettant de créer le package Debian (actuellement http://ftp.de.debian.org/debian/pool/main/c/codelite/codelite_6.1.1+dfsg-4.debian.tar.xz , linké depuis l'interface Web et téléchargeable avec `apt-get source`), en particulier le répertoire debian/patches (un endroit tout à fait surprenant pour trouver des patches, n'est-il pas ?), montre que le debundling est loin d'être la mer à boire pour CodeLite. Le premier des 4 patches de debundling est un one-liner; tous les hunks du deuxième sauf les deux premiers sont générables par simple substitution; le troisième est le moins simple, mais fait seulement 106 lignes en comptant le header et tous les contextes; le quatrième, de diffstat +3/-5, ne présente aucune difficulté.

Mais poster ./686 et ./693 réclame beaucoup moins d'effort, de réflexion, de volonté d'être constructif, que de regarder réellement, en moins de 5 minutes, ce qu'il en est, et aussi que de rédiger ce post.

EDIT: ah zut, les spoilers ne sont pas repliables, sur yAronet.

Meowcate (./695) :
Peut-être simplement le fait que si Debian propose CodeLite et pas Fedora, c'est Debian qui a un problème.

OK, Debian a fait le travail de nettoyer le bordel bundlé, c'est bien pour eux, et puis? Personne n'a voulu perdre son temps avec ça chez nous (Fedora) et je comprends. C'est casse-pieds de devoir défaire du bundling aggressif, je déteste ce genre d'upstream. Et vu qu'il y a assez d'autres EDIs qui ne sont pas comme ça…

Je dois me tromper sur mon système alors. J'avais l'illusion de penser que quand j'installais un logiciel avec ses dépendances, lesdites dépendances suivaient également une mise à jour automatique.

Si c'est un logiciel packagé correctement, avec les dépendances débundlées, oui. Si le logiciel bundle sa propre copie des dépendances, non. C'est bien pour ça qu'il faut débundler et que les upstreams qui bundlent les dépendances ne font que nous faire du travail supplémentaire.

Primo, quand je veux installer KDevelop, il faut que j'installe QUOI si je veux l'essayer sans encore savoir ce que je veux ?

Ben, "kdevelop" tout court.

Non parce que CodeLite, en deux install c'est fait.

Un de trop. (Pourquoi ce sous-paquetage -plugins?)

Et puis quand on parle du bon packaging, c'est oublier un peu vite la dépendance au bureau utilisé.

KDevelop marche parfaitement sous n'importe quel environnement de bureau, il suffit d'avoir les bibliothèques qu'il faut, et apt-get te les installe sans problèmes.

spectras (./698) :
Meowcat> c'est pas vraiment du packaging. Le fait est que Kdevelop est une application KDE, et que pour cette raison, si tu n'utilises pas un environnement KDE ça l'exclue pratiquement d'office. Un peu comme il ne te viendrait pas à l'idée d'utiliser Kate ou Kmail dans un environnement Gnome. Pour cette raison, ce n'est pas une vraie dépendance mais plutôt une contrainte : Kdevelop, c'est pour KDE.Et donc la question Kdevelop ou Codelite ne peut se poser que si tu utilises KDE, si ce n'est pas le cas, c'est forcément Codelite.

Pas d'accord, cf. ci-dessus.

Lionel Debroux (./702) :
http://ftp.de.debian.org/debian/pool/main/c/codelite/codelite_6.1.1+dfsg-4.debian.tar.xz

Le +dfsg signifie qu'en plus upstream bundle des trucs non-libres!

le debundling est loin d'être la mer à boire pour CodeLite.

Ça reste du travail totalement inutile pour nous packageurs, je comprends que personne n'est intéressé à faire ce travail pour Fedora.

Oui bien sur tout le monde va installer 400Mo de libs pour un IDE qui fait la meme taille (et qui est d'une qualité douteuse en plus)

Le +dfsg signifie qu'en plus upstream bundle des trucs non-libres!

Les vrais trucs non libres sont très nettement minoritaires dans l'énorme collection de packages Debian, et presque toujours dans la partie non-free des repositories Debian. Il est facile de voir que codelite et codelite-plugins sont dans la partie main.

Comme un seul clic vers le site de CodeLite te l'aurait montré, CodeLite est GPLv2, avec une exception pour les plugins ("Plugins developed For CodeLite (other than the ones that are shipped with the official installer provided by the CodeLite team), are allowed to remain closed sourced and can be distributed under any license.").
Quant au debundling: LLVM/Clang et sqlite sont bien connus pour être sous des licences open source beaucoup plus permissives que la GPL (*); cppcheck est sous GPLv3 d'après le COPYING de son repository; Unittest++ est sous licence MIT d'après le LICENSE de son repository.
Bref, pour moi, en 5 minutes, il n'est pas évident de voir ce qui serait "non libre" dans codelite, même avant debundling.

Rappelons que même si ce n'est pas forcément la raison du "dfsg" pour CodeLite, Debian considère comme non libres certaines choses de la FSF.


Mais on commence à s'éloigner du sujet.


*: c'est d'ailleurs grâce à ça, en plus des avantages techniques à utiliser une base de code beaucoup plus moderne et beaucoup plus flexible que GCC/binutils, que LLVM/Clang a pris un tel essor. GCC a du reste tellement bien compris les avantages techniques et de licence que LLVM offre, que l'infrastructure de plugins longtemps bloquée par RMS a enfin été mise en place il y a des années, que l'AST est devenu plus fidèle au source d'origine, que des opérations supplémentaires visant à réduire la dette technique de GCC ont été et continuent d'être menées, qu'un peu de C++ a été ajouté dans GCC à des fins de type safety et d'efficacité, qu'une librairie pour faire du JIT a été ajoutée récemment à GCC, etc.

Upstream bundle des binaires, dont certains visiblement sans la source correspondante!
Cf. par exemple Runtime/File2Hex.exe (dans ce cas, la source est dans le dossier File2Hex), Runtime/patch.exe (source? Si c'est GNU patch, ils sont obligés de la proposer! Si c'est un truc BSD, c'est légal, mais reste contraire aux règles de Debian et Fedora), Runtime/rm.exe (source? Même discours que pour patch), Runtime/OpenTerm (binaire pour je ne sais pas quelle plateforme, peut-être non-libre, source introuvable également).

En plus, ils veulent qu'on patche son wxWidgets (cf. le dossier patches).

Bref, c'est un excellent exemple d'un projet totalement bordélique qui est un cauchemar à packager!

Quel scandale, l'auteur a commis l'erreur de faire un soft agréable pour ses utilisateurs, au lieu de le faire agréable pour les packageurs !

Kevin Kofler (./707) :
Bref, c'est un excellent exemple d'un projet totalement bordélique qui est un cauchemar à packager!

Qu'est ce que ça peut te faire au final, t'es pas packager...

Je pensais pas que ce petit plus que j'ai cité, parce que ça facilite radicalement l'installation sous Windows, allait faire couler autant d'octets

Alors un autre petit plus : compatibilité OS X, qui n'a rien à voir avec la compatibilité théorique d'un Codeblocks par exemple, car cette fois, l'auteur a OS X, le soft est donc très testé sur cet OS.

Ce que Kevin dit est juste si on se place au niveau du packaging pur. D'un point de vue philosophie linux/package manager il n'y a pas grand chose à discuter, c'est mal de bundler des libs avec son soft. Les Linuxiens sont les premiers à chier sur Mac parce que c'est la convention de bundler, du coup faut être cohérent, et c'est pas qqch qu'on peut reprocher à Kevin.
Maintenant je pense aussi que le packaging n'est qu'un petit détail dans un soft, c'est un peu comme juger une ville en prenant une coupe des 2ème étages de tous les bâtiments, et pour ma part je préfère avoir un truc qui "just works"™. Pour moi tu pourrais même à la limite bundler tout le framework en user mode avec ton appli, ça ferait qu'on pourrait dropper Win32 mais que les applis marcheraient toujours dans 10 ans.

Folco (./710) :
Alors un autre petit plus : compatibilité OS X, qui n'a rien à voir avec la compatibilité théorique d'un Codeblocks par exemple, car cette fois, l'auteur a OS X, le soft est donc très testé sur cet OS.

C'est courant de nos jours. C'est la même chose pour les produits de JetBrains par exemple, ils supportent le "retina" très bien sous Mac mais quand t'es sous un autre OS ça scale super mal (en gros il te faut scaler les fontes manuellement, et n'affecte pas les icônes et tout).

Brunni (./711) :
pour ma part je préfère avoir un truc qui "just works"

C'est uniquement pour ça que j'ai parlé du packaging, ici on est sur un forum de user, pas sur la ML des packageurs de je ne sais quelle distro.

vince (./12) :
Qu'est ce que ça peut te faire au final, t'es pas packager...

Si.

Brunni (./14) :
et pour ma part je préfère avoir un truc qui "just works"™.

yum install kdevelop
Just works.

On s'en fiche toujours.

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

Et le topic a été forké, ce n'est plus hors sujet maintenant.

Il n'empêche qu'il n'y a que pour toi que ça soit un problème plus que fondamental.

Pourrais-tu s'il te plaît expliquer à ces newbies comment fonctionnent les bibliothèques partagées?

Non ça va j'ai assez de types de bibliothèques dans la tête comme ça, et t'es pas obligé d'être hautain.

Et outre ça ça ne répond pas à la question de pourquoi ça devrait être ça et pas autre chose.

Kevin > C'est peut-être plus hors-sujet, mais ça n'intéresse toujours personne à part toi.

(en attendant, Folco a convaincu vachement plus de monde que CodeLite valait le coup que toi avec KDevelop)

Kevin Kofler (./20) :
Call : PpHd appelé(e) sur ce topic...
Pourrais-tu s'il te plaît expliquer à ces newbies comment fonctionnent les bibliothèques partagées?

C'est vrai, le mécanisme des bibliothèques partagées est une excellente chose permise par le kernel, il faut être un gros noob pour prétendre le contraire.

flanker (./23) :
(en attendant, Folco a convaincu vachement plus de monde que CodeLite valait le coup que toi avec KDevelop)

→ topics/4-164999-f-moved-mon-langage-est-mieux-que-le-tien/25#721

Ce qui m'interpelle sur ce sujet, c'est ça :

Kevin Kofler (./2) :
Et CodeLite n'est même pas dans les dépôts officiels de Fedora (probablement justement à cause de cette attitude: Les logiciels qui bundlent tout sont une horreur à packager parce qu'il faut passer son temps à virer tous les trucs bundlés et utiliser des dépendances à la place), donc trop compliqué à installer → poubelle.

Je n'arrive pas à décider ce qu'est censé exprimer le smiley final

C'est pour dire qu'un programme qui semble être apprécié des utilisateurs n'est pas proposé par cette distribution, et c'est bien, faut en être fier ?
C'est pour dire que ceux chargés de l'empaquetage pour cette distribution sont fainéants (contrairement, semble-t-il, à d'autres), et c'est bien, faut en être fier ?
C'est parce que mettre une flèche vers poubelle est vraiment très lumineux, et c'est bien, faut en être fier ?
Autre chose ?

Le "" porte sur le "→ poubelle" et signifie que je vous montre la langue en jetant ce logiciel trop compliqué à installer à la poubelle.

Je résume: il exprime en quoi il vaut mieux que toi.

Ne dites pas

→ poubelle.

Mais plutôt

→ poubelle direct.

Sinon, je ne savais pas que le fork pouvait être récursif. C'est joli les 2 paires de ciseaux à côté du titre de ce topic