Sommaire
- Y a t il une bonne raison technique à avoir des .deb .rpn …etc ?
- c'est une perte de temps et d'énergie incroyable
- on confond la norme et le logiciel qui l'implémente
Ça fait longtemps qu'on n'a pas discutée l'intérêt d'avoir tant de formats de paquets différents sous linux, non ?
J'écris en réaction à ce commentaire de la dépêche sur Newebe. Sachant le potentiel de troll du débat, je préfère créer un journal à part plutôt que trop polluer la dépêche.
Bon je sais…, on n'est pas encore tout à fait vendredi… j'adresse un sourire méprisant à celui qui m'expliquera que 12 000 systèmes de paquets c'est bien pour la diversité, par contre "trolldi c'est trolldi et aucun écart ne peut être toléré…"
Si vous sentez déjà à ce stade l'énervement monter, il faut peut être arrêter de lire ici. Il est de toute façon peu probable que ce qui suit change le monde.
Le commentaire en question dont je ne partage pas le point de vue :
non, je répondais juste au marronnier que c'est trop compliqué de distribuer et qu'il faudrait qu'un seul truc au lieu de toutes ces distributions. C'est un truc à courte vue de réclamer la simplification. C'est comme en matière génétique, l'objectif est d'avoir un patrimoine le plus diversifié possible pour qu'avec le temps on puisse sélectionner celui qui nous convient le mieux, des types de paquets disparaissent, d'autres apparaissent, pour satisfaire des besoins différents.
C'est cet écosystème diversifié qui fait la force du libre plutôt que la simplicité d'une simplification uniformisante. Les gens qui veulent un système unifié, y'a déjà windows et mac : ils y trouveront leur bonheur…et au pire…. un bon gros blob binaire en statique
Il résume assez bien les arguments de ceux qui n'ont pas encore compris que j'avais raison.
Y a t il une bonne raison technique à avoir des .deb .rpn …etc ?
Je ne suis pas un expert de ces formats, je laisse les commentateurs de m'éclairer sur les obstacles techniques insurmontables.
Vu de ma lorgnette, je préfèrerais avoir un format moins bon que .deb ou .rpm mais faisant consensus !
Je suis sur en plus, que des gens intelligents pourraient concevoir un format standard extensible, au cas ou, ils oublieraient un truc au premier jet. C'est le cas de xmpp par exemple.
Il faudrait commencer par s’asseoir autour d'une table et essayer. Le problème c'est que si je fais ça avec mes trois potes, on va se retrouver avec X+1 formats de paquets (cf le fameux dessin xkcd). Pour que ça marche, il faut que ça parte de gens influents dans les grandes distribs.
c'est une perte de temps et d'énergie incroyable
Quel gâchis de refaire plus ou moins la même chose chacun dans son coin. En plus, c'est une tache ingrate, je me dis quel si la moitié des créateurs de paquets consacraient ce temps à, par exemple, écrire de la documentation, l'univers du libre ne s'en porterai pas plus mal.
Pour cette raison je n'ai pas tellement envie de contribuer à créer des paquets, j'aurais l'impression de perdre mon temps.
Qui n'a jamais laisser tomber le test d'un soft parce-que l'installation est trop galère ?
Combien de soft n'ont jamais eu de version linux parce qu'à la vue de la complexité de fournir x paquets, la boite à pris peur ?
on confond la norme et le logiciel qui l'implémente
Bon sang, je demande pas un linux au garde à vous, débarassé de sa diversité, c'est en grande partie pour cette diversité que je l'utilise au quotidien depuis des années.
Même chez les linuxiens il y a des normes, pour le bien de tous. Si tout le monde se se prend à inventer son POSIX à lui, son SMTP, son ssl c'est pas de la diversité, c'est s'isoler du reste du monde. Bien sur, on peut et on doit innover, mais à condition d'apporter quelque chose en plus, pas juste pour le plaisir de se différencier.
Je ne vais pas créer ma distib linux en collant le répertoire utilisateur dans /etc les logs dans /dev et les binaires dans /var/log sous prétexte que la diversité c'est bien.
Un format de paquet c'est destiné à la diffusion, pour cela, il faut un format standard ! Après, libre à chacun de développer et utiliser le logiciel qui lui plait. Je suis très content d'avoir le choix entre Gnome, KDE, QT, GTK+, …etc, c'est de la diversité et tant mieux. Au delà de ça, tout les effort du style freedesktop sont bienvenus pour gagner en Interopérabilité.
Les outils qui essayent de de générer des paquets pour un peu toutes les distribs ne font que contourner un problème qu'on c'est nous même créés au prix d'une usine à gaz.
Le parallèle avec les langues : c'est très bien que plein de langues existent dans le monde, c'est la diversité culturelle, il faut l'entretenir. N'empêche que pour développer un logiciel libre, il vaut mieux parler anglais. C'est le seul moyen de faciliter l'accès d'un maximum de personnes. Ça m'arrange pas plus que ça, ma langue maternelle est le français. Je peux faire l'effort de communiquer en anglais pour des raisons pragmatiques. Apprendre une autre langue, c'est gérable, s'il fallait que je parle russe, japonais ou basque en fonction du projet concerné, je laisse tomber avant de commencer, trop d'efforts.
Allez bisous, lâchez vous… attention quand même, si vous êtes trop méchants, j'invoque Zenitram en renfort ! bah, et puis faite comme vous voudrez, il viendra probablement de toute façon.
# Le format des paquets n'est pas le problème
Posté par Renault (site web personnel) . Évalué à 10.
Le format de paquet n'est pas la source principale de difficulté pour les empaqueteurs d'applications. Après tout, que ce soit RPM ou DEB il y a des outils performants qui simplifient a tâche.
La difficulté est de réaliser une intégration, c'est à dire fournir une liste d'applications cohérentes qui dans une version fixe pour chacun d'eux l'ensemble du système fonctionne efficacement. Ce qui nécessite souvent des correctifs de toutes parts (car les applications font références à des versions différentes de bibliothèques mais dont on ne veut qu'une version de disponible à la fois), mais aussi à des tests approfondis, etc.
Si tu veux fournir une application sous Linux très simplement, tu compiles tout en statique pour une architecture donnée et tu distribues ça comme une application Windows et c'est réglé. Comme tout est compilé statiquement tu n'as pas le soucis d'intégration avec l'environnement actuel et cela fonctionne partout. De nombreux programmes propriétaires font ça.
Bref, a multitude des formats de paquet est souvent l'épouvantail d'un problème qui est en réalité tout autre.
Techniquement le LSB a tranché pour RPM, mais de nombreuses personnes n'aimant pas la LSB ça n'aide pas. De plus dans un écosystème libre, qui signifie que globalement tout le monde peut faire ce qu'il veut, il est difficile d'imposer une norme à tout le monde. Si demain Gajim veut incorporer des extensions spécifiques à XMPP, il peut et personne ne pourra l'en empêcher.
Le syndrome du NIH a de beaux jours devant lui.
POSIX est vieux, n'a pas tranché sur de nombreux aspects et de nombreux projets lui font cordialement un doigt d'honneur comme les utilitaires GNU qui ajoutent de nombreuses extensions aux programmes de bases.
Pourtant, fondamentalement, qu'est-ce qui t'en empêche ? C'est l'avantage du code libre, tout le monde peut le modifier pour en faire n'importe quoi. Et parfois ce n'importe quoi arrive à générer des trucs sympas avec d'autres trucs moins biens ce qui fait qu'il est adopté.
Je suis sûr que son avis sur la question sera plus réfléchi et pertinent que la prose de nombre d'entre nous.
[^] # Re: Le format des paquets n'est pas le problème
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
D'ailleurs, c'est assez facile à faire. On reprends toutes les dépendances qu'on met dans tar.gz puis on remplace la ou les commandes par un wrapper qui place les bonnes variables d'environnement (merci UNIX). Matlab fait cela très bien effectivement (ainsi que Comsol…). C'est ainsi que tu as N version de java, python, openmpi… sous /opt (si tu les installes la bas).
Ansys semble incapable de faire cela correctement. La dernière version qu'on a fait plus de 23Go et malgré cela, on arrive à avoir des merdes selon les distrib… Il faut dire qu'il y a dans leur workbench un paquet de merde en .NET 32 bits, tout cela tourne via un mono embarqué pour des machines amd64…
[^] # Re: Le format des paquets n'est pas le problème
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il faudrait voir la taille des paquets, avec des compilations de lib statiques avec simplification introduit dans le linker (logiquement, il vire maintenant les symboles non utilisés et pas seulement les .o). Si cela se trouve le travail de factorisation, n'est pas tellement utile.
Sinon, tu bosses où pour Ansys ? A Lyon ?
"La première sécurité est la liberté"
[^] # Re: Le format des paquets n'est pas le problème
Posté par gnx . Évalué à 2.
Il n'a pas dit qu'il bossait pour Ansys.
[^] # Re: Le format des paquets n'est pas le problème
Posté par Dr BG (site web personnel) . Évalué à 3.
Je pense que sa confusion vient de
qui mal lue peut laisser croire qu'ils ont réalisé la dernière version. Alors que la suite de la phrase lève tout ambiguïté : la version qu'ils possèdent fait plus de…
[^] # Re: Le format des paquets n'est pas le problème
Posté par gnx . Évalué à 1.
L'orthographe aussi… :-)
[^] # Re: Le format des paquets n'est pas le problème
Posté par Dr BG (site web personnel) . Évalué à 3.
J'aurai dit la grammaire aussi, mais bon… en même temps, l'auteur original aurait bien pu faire cette faute courante.
[^] # Re: Le format des paquets n'est pas le problème
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Exact, je suis dans le supérieur / publique.
Je sais que je fais pas mal de fautes souvent parce que je vais trop…
"La dernière version qu'on a fait plus de 23Go" signifie pas "qu'on a fait" mais la version qu'on a, elle fait. Effectivement, selon le rythme, cette phrase prête à confusion !
Je pense que je ne bosserais jamais pour Ansys. Cette boite américaine ne m’intéresse pas et leur workbench sous GNU/Linux est une daube en boite indigne de leur prestige.
[^] # Re: Le format des paquets n'est pas le problème
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
En fait, je bosse pour une filial de Ansys.
"La première sécurité est la liberté"
[^] # Re: Le format des paquets n'est pas le problème
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Ben si tu peux faire remonter que leur usines à gaz est une daube ;-) Ils devraient prendre des cours chez Mathworks sincèrement (ou COMSOL…). J'ai jamais eu cela avec un autre logiciel privateur. Si tu arrives à faire passer un message, tant mieux.
find /opt/ansys/15.0/ -executable -a -type f -exec file {} \+ | grep 'executable for MS Windows'| grep 32-bit | wc -l
441
find /opt/ansys/15.0/ -executable -a -type f -exec file {} \+ | grep 'executable for MS Windows'| grep DLL | wc -l
376
find /opt/ansys/15.0/ -executable -a -type f -exec file {} \+ | grep 'executable for MS Windows'| grep console | wc -l
408
Je ne parle pas de leur daube en surcouche de flexlm (les seuls à faire cela) et l'outil que graphique pour choisir sa licence… Impossible de le faire via une variable d'environnement ou un paramètre de la ligne de commande. Au final, j'ai fais une fonction bash qui copie un fichier qui va bien dans le .ansys de l'utilisateur mais c'est pas officiel et surtout pas robuste en cas d'appel concomitant !
Pour la taille, on tend vers de la gonflette pure, sachant que la version 13 était déjà très largement le plus gros logiciel privateur dans mon laboratoire. C'est pas gênant avec les SSD car sinon, ça n'accélère pas l'ouverture non plus… Bref, anti-écologique.
du -sh /opt/ansys/*
9,0G /opt/ansys/13.0
23G /opt/ansys/15.0
ls -l /opt/ansys/15.0/v150/commonfiles/CPython/linx64/python/bin/python*
-rwxr-xr-x 1 root root 7814 15 oct. 2013 /opt/ansys/15.0/v150/commonfiles/CPython/linx64/python/bin/python
-rwxr-xr-x 1 root root 7814 15 oct. 2013 /opt/ansys/15.0/v150/commonfiles/CPython/linx64/python/bin/python2.6
-rwxr-xr-x 1 root root 1471 15 oct. 2013 /opt/ansys/15.0/v150/commonfiles/CPython/linx64/python/bin/python2.6-config
-rwxr-xr-x 1 root root 1471 15 oct. 2013 /opt/ansys/15.0/v150/commonfiles/CPython/linx64/python/bin/python-config
/opt/ansys/15.0/v150/commonfiles/CPython/2_7_3/linx64/Release/python/bin/python2.7
On ne parlera pas non plus du /ansys_machin qu'il souhaite te mettre à la racine (heureusement, on l'évite facilement). Ni du support absolument pas réceptif si tu n'est pas en RHEL (va te mettre en RHEL sur un cluster !!). J'ai rarement vu des gens aussi borné. Quand au volet commercial, on a beau leur former une partie de leurs ingénieurs, nada.
[^] # Re: Le format des paquets n'est pas le problème
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Ansys est vaste, tu parles de quel soft exactement ? Les outils sont la plus part du temps issue de boites différentes, et la mise en commun n'est sans doute pas fait au niveau du code. C'est très compliqué de partager le même code pour des équipes dispersées dans le monde.
Je bosse sur SCADE. Il y a un seul module qui semble anormalement gros. C'est une machine virtuelle qui évalue la vitesse d'un code, avec un code OEM d'une autre boite. Le soft pèse autour de 1Go. Il y a plusieurs type de cibles (différentes versions de powerpc). C'est 1 Go en plus par cible ! Tout est dupliqué à chaque fois.
"La première sécurité est la liberté"
[^] # Re: Le format des paquets n'est pas le problème
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je n'ai pas vraiment envie de dire la liste des modules que nous avons mais je pense que le gros du merdier proviens du workbench qui me semble un socle commun et qui est clairement développé sous Windows. D'ailleurs, rien que le nom est anormal : run_wb2. Qui met des soulignés dans les noms de ses programmes ?
Enfin, si Ansys n'est même pas capable de fixer une version de Python, cela m'inquiète sur leur stratégie de groupe… Franchement, ils alignent quand même coté prix.
[^] # Re: Le format des paquets n'est pas le problème
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Oups, j'ai été médisant, c'est runwb2 et non run_wb2…
[^] # Re: Le format des paquets n'est pas le problème
Posté par arnaudus . Évalué à 6.
Osef un peu de la taille des paquets, non? Pour moi, le principal avantage de lier dynamiquement les bibliothèques, c'est d'avoir un système modulaire. Du coup s'il y a un bug ou une faille de sécurité dans la lib trucmuche, je dois mettre à jour la lib trucmuche et seulement cette lib, et pas la totalité de ma distribution. Si je veux patcher ma lib trucmuche, tout le monde va utiliser ma version patchée. Le gain de RAM est toujours appréciable, mais ça n'est pas un argument majeur.
# .lpo
Posté par Le Gab . Évalué à 7.
Lennart devrait nous régler la question dans pas très longtemps, je pense.
Sinon oui, cette situation est frustrante à plus d'un titre.
Idées: Moins de distros, une "baseline" stable et ce sur la durée, un standard pour lier les bibliothèques, une sorte de super autotools. Patchage de binaires au lieu de se retaper une installation/compilation.
[^] # Re: .lpo
Posté par saltimbanque (site web personnel) . Évalué à 2.
la question va en effet se régler par la disparition des paquets "classiques".
[^] # Re: .lpo
Posté par xcomcmdr . Évalué à 10.
Bientôt packetd ?
Avec intégration à systemd pour lancer packetd dès qu'une connexion Internet est disponible, et intégration à PulseAudio pour signaler les actions du gestionnaire de paquets via des messages sonores !
La grande classe, quoi.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: .lpo
Posté par julmx . Évalué à 7.
oui oui, avec un PKGBUILD au format binaire
[^] # Re: .lpo
Posté par ariasuni . Évalué à 5.
Va quand même falloir innover sur les blagues.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: .lpo
Posté par gnx . Évalué à 10.
C'est prévu. Avec
blagd, retrouve les piques les plus originales de Lennart à chaque démarrage dans ton splash-screen (dépend d'OpenGLd). Qualité garantie grâce à une suite de 3 tests déroulée 2 fois sur le portable de maman Poettering.Bon, par contre, il faudra attendre la version 27 (rassurez-vous, ça ne fait que 3 mois) pour avoir l'affichage optionnel en ASCII, pour l'instant c'est affiché directement en binaire (mais avec un gain de 13% de FPS, petits veinards).
[^] # Re: .lpo
Posté par GnunuX (site web personnel) . Évalué à 5.
C'est un peu la définition de la LSB non ?
[^] # Re: .lpo
Posté par reno . Évalué à 2.
J'ignore si tu plaisante ou pas, mais systemd a un support des bacs à sables, comme les bacs à sables et le packaging ont un lien (c'est beaucoup plus simple si tu peux installer des packages dans un bac à sable sans que le système hôte les voient), ce n'est pas à exclure qu'il y ai de l'action de ce coté là..
Pour revenir au sujet du journal, il y a 2 types d'outils de packaging:
-les "classiques" qui ont grosso-modo les mêmes fonctionnalités: rpm vs deb par exemple.
Dans ce cas là effectivement, c'est une diversité négative: plus d'outils a apprendre qui font la même chose, donc une perte de temps et d'énergie considérable.
-ceux qui apportent des nouvelles fonctionnalités: Nix là, c'est justifié.
Mais bien sûr, Nix a AUSSI un clone Guix, pfff..
Mais bon dans tout les cas, la duplication d'efforts dans ce domaine existe depuis longtemps, donc je ne vois pas trop la situation évoluer..
# Le paquet masque le repo
Posté par etenil . Évalué à 10.
Si j'ai bien saisi, ton cheval de bataille est l'interopérabilité des distros.
Au premier abord, le format de paquet peut sembler fautif, mais il n'est guère qu'un symptôme. Les gestionnaires de paquet font en effet bien davantage que simplement décompresser le paquet et exécuter un script ou deux, il y a aussi et surtout la gestion des dépendances.
Et c'est surtout la que le bat blesse. Les distros ont toutes des conventions de nommage des paquets différentes, des clashs de versions etc. Qui font que ton rpm pour fedora va casser sur suse (par exemple). Et ça ça va être drôlement plus coton a standardiser qu'un format de fichier!
[^] # Re: Le paquet masque le repo
Posté par julmx . Évalué à 0.
C'est vrai que le problème est complexe et je n'ai parlé que d'un aspect. Après, le problème des différentes conventions de nommage n'est pas non plus insurmontable. Il faudrait réussir à ce mettre d'accord ou maintenir au pire un index qui ferait les équivalences.
[^] # Re: Le paquet masque le repo
Posté par hervé Couvelard . Évalué à 8.
ouais et un index pour les versions des lib, et un index pour le toolkit, et un index….
le paquet n'est qu'un épiphénomène, il faut avoir roulé sa bosse dans plein de distro, avoir compilé/installé plein de soft pour comprendre que le problème n'est pas là. Bien sûr le dev, il aimerait bien un clic et pafff le paquet pour tout le monde, mais celui qui se fait chier à entretenir son linux c'est pas pour se retrouver avec le même que les autres utilisateurs, il le personnalise et à partir de ce moment là, tout est foutu. Tu vois sur mes nouvelles machines je pose ni kde ni gnome ni xfce. Et je trouve con qu'il y ait plusieurs toolkit, je dois installer tout plein de paquets pour faire la même chose : afficher une fenêtre. Pourquoi on ferait pas un toolkit qui utilise peu de ressources et que tout le monde utiliserait celui-la, plutôt que de tirer 150 Mo pour un simple éditeur de texte ou de dessin ?
Il y aura toujours un truc qui fera chier, et je peux t'assurer, c'est pas le format de paquet, car il est tellement simple de faire un truc qui compile à partir des sources, le truc c'est tout ce qu'il y a autour.
[^] # Re: Le paquet masque le repo
Posté par xcomcmdr . Évalué à 7.
Qt vaincra.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Le paquet masque le repo
Posté par claudex . Évalué à 5.
C'est ce que fais cmake avec cpackage. J'avais pensé à un système pour générer automatiquement des paquets pour la plupart des distributions de manière pas trop moche. Ça me semblait possible à faire. Il suffirait d'un fichier de conf qui définit:
Ça permettrait de générer des fichiers de construction des paquets qui pourrait être utilisé (voire automatisé) pour l'opensuse build service. Bien sûr, ça n'aurait pas la qualité des paquets des distributions mais ça peut faciliter le travail de ces dernières, ça permet aux développeurs de fournir leur travail pour ceux qui veulent tester facilement, tout en évitant un travail de cochon (beaucoup de développeur n'aiment pas cette partie là).
« 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: Le paquet masque le repo
Posté par freem . Évalué à 1.
Hum… je proteste, je n'ai fait qu'utiliser Debian, et je le comprend bien.
Bon, après, je suis un programmeur qui préfère le C++ aux autres, malgré ses défauts en terme de compatibilité: ABI non standardisée, donc une simple différence de version entre 2 compilos peut faire péter un binaire.
Je suis aussi le genre qui vise un système réellement minimum, quitte à faire de faux packages, par exemple pour gstreamer qui est régulièrement en dépendance dure ( "depend" chez Debian ) pour "rien" ( les logiciels fonctionnant parfaitement sans ce truc, j'ai envie de dire qu'il devrait être en "recommended" ) et dconf.
J'imagine que ça m'aide à comprendre qu'effectivement, le problème n'est pas le format de package.
D'ailleurs, si c'était vraiment une importante cause de problème, il existe alien pour installer du rpm sur une Debian, et packagekit qui lui vise, si j'ai bien compris sa description dans aptitude, à fournir justement cette couche d'abstraction qui manque tant selon l'auteur du journal.
Ces solutions n'ont absolument rien changé, j'ai l'impression, installer un rpm sur une Debian est toujours aussi casse-gueule, et même installer un deb d'Ubuntu c'est s'exposer à des emmerdes monstres ( alors qu'en théorie, Ubuntu est basée sur Debian sid ).
[^] # Re: Le paquet masque le repo
Posté par barmic . Évalué à 4.
Ce n'est pas parce que ce n'est pas le seul frein que ça n'en est pas un. C'est juste probablement le plus simple (malgrès le fait que ce soit déjà très compliqué). Comme on est trolldi on va commencer les images à 2 sous, c'est comme si tu disais que ça ne sert à rien d'utiliser le même alphabet que les japonais parce que de toute manière on comprend que dalle à ce qu'ils racontent.
La problématique de l'intégration est un problème très complexe. Il faut non seulement gérer la compatibilité entre un paquet et ses dépendances, mais il faut en plus faire des choix qui sont de base discutables. Ils demandent une organisation d'ensemble pour avoir des conventions (nommage des paquets). Le fait d'avoir un format commun permettrait aux distributions plus petites de simplifier le portage de paquets et d'avoir une certaines synergie entre les distributions.
Au lieu de ça on segmente, on fait précisément ce que l'on reproche à Apple dans le journal sur Swift, on crée de l'incompatibilité sans but réel. C'est sûr que c'est plus agréable pour les gros (RedHat en tête) et les petits peuvent faire leur truc dans leur coins plutôt que de tenter d'améliorer l'existant (quitte à faire un fork).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le paquet masque le repo
Posté par claudex . Évalué à 4.
Bof, toute la conversion de paquet peut s'automatiser (cf. alien). Si tu résoud les autres problème, tu passe un coup d'alien et ton paquets est installable.
« 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: Le paquet masque le repo
Posté par barmic . Évalué à 5.
Pas vraiment non. alien gère les 2 formats de paquets les plus répendu, mais pour les ebuild ou les pkgbuild c'est plus tout à fait la même blague et faire une conversion de ces formats vers du rpm ou du deb va donner un paquet de goret qui n'a de paquet que de nom (qui ne se met pas à jour correctement, qui ne se déinstalle pas forcément très bien). Faut arrêter de croire que alien est complet et que c'est une solution, c'est le truc que tu utilise en te disant que c'est crade mais moins pire qu'autre chose (comme checkinstall).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le paquet masque le repo
Posté par claudex . Évalué à 3.
Il ne gère pas mais ce ne serait pas très compliquer de le faire (pour les paquets sources, évidemment). Par exemple, convertir le
src_compile()en%build, lesrc_install()en%install…« 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: Le paquet masque le repo
Posté par barmic . Évalué à 3.
Et la gestion des fichiers de configuration par exemple tu la fait comment ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le paquet masque le repo
Posté par claudex . Évalué à 3.
Je ne vois pas ce que tu veux dire. Ils ne sont pas traité différemment que les fichiers binaires dans un RPM ou un ebuild il me semble.
« 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
# lol
Posté par hervé Couvelard . Évalué à 8.
je me dis quel si la moitié des personnes qui écrivent des journaux sur les formats de paquet qui sont trop nombreux consacraient ce temps à, par exemple, écrire de la documentation, l'univers du libre ne s'en porterai pas plus mal.
[^] # Re: lol
Posté par julmx . Évalué à 9.
On est deux, et là c'est l'autre qui est en train d'écrire de la doc
[^] # Re: lol
Posté par F(log) . Évalué à -1.
moi je suis decu qu'il n'y ai pas le liens vers le dessin xkcd :(
[^] # Re: lol
Posté par julmx . Évalué à 1.
[^] # Re: lol
Posté par kowalsky . Évalué à 2.
Il manque le "alt" (c'est un standard aussi cette remarque) !
# En résumé
Posté par Misc (site web personnel) . Évalué à 10.
Le souci, c'est que les gens sont contre la diversité, sauf si ça implique de changer ce qu'ils utilisent, auquel cas, c'est liberticide.
Exemple, systemd, gnome3, etc.
Donc tenter de résoudre ça de façon générique est impossible, il y aune balance, et la balance est "celui fait le travail décide". Bien sur, ça va faire des frustrations, mais bon, les gens sont libres.
# J'essaye de me soigner
Posté par Zenitram (site web personnel) . Évalué à -3.
J'essaye de me soigner, et arrêter d'essayer d'expliquer que ça pose problème, de toutes façon les gens ne veulent pas écouter, et vont (dejà en quelques minutes, suffit de voir les première réations) que ce n'est pas le problème, ça fait 15 ans que Linux est prêt pour le desktop (sic) mais c'est pas grave, mais ne vont surtout pas dire ce qui est le problème (parce qu'ils ne sont pas d'accord entre eux, et que d'autres diront que ce n'est pas le problème, au final il n'y a aucun problème et c'est la faute des autres qui sont pas gentils, le truc classique).
Désolé, je vais te laisser seul, un seul commentaire pour dire que je suis la, et me forcer qu'à lire pour rigoler des 36 excuses bidons qui vont dire que ce n'est pas un problème, rigoler sur l'auto-division pour mieux laisser régner les autres (qui ont leur propre système de paquet, mais sont d'une plus gros, et de deux permettent aussi le proprio donc en pratique divisent moins et… Attirent les développeurs!), ici la cause est perdue et il vaut mieux faire comme beaucoup de développeurs libristes : en avoir assez des merdes égocentriques des développeurs de Linux sur le desktop, les laisser se déchirer entre eux plutôt que de proposer un bon OS, et passer à Mac pour sa machine de tous les jours. C'est le résultat, n'en déplaise aux puristes (de moisn en moins nombreux) qui hurlent quand ils voient une salle de conf sur des logiciels libres remplis de Mac.
[^] # Re: J'essaye de me soigner
Posté par Renault (site web personnel) . Évalué à 5.
Comment expliques-tu alors que des programmes propriétaires compilés statiquement permettent de s'installer sur la plupart des distributions (moyennant une version de Linux compatible, si le programme en dépend) ?
En soit, rien, peut être que ce sera moins bien intégré mais c'est pareil pour les applications externes de Mac OS X ou Windows.
C'est sûr que tu ne profites pas de la puissance du gestionnaire de paquet, mais ça a le mérite de fonctionner comme pour la concurrence. Personnellement je ne vois pas en quoi le fait que ce soit RPM ou DEB soit un frein vu qu'une alternative universelle existe.
Mais je suis d'accord sur le fait que la diversité peut être un gaspillage d'énergie en donnant des ressources à des projets sans grands intérêts. Mais le libre ne peut empêcher cette diversité donc comment l'éviter étant donné qu'on ne peut forcer les gens à agir ainsi ?
[^] # Re: J'essaye de me soigner
Posté par claudex . Évalué à 10.
En gros, tu n'as pas lu les commentaires, tu as juste imaginer leur contenu. Personne n'a dit que ce n'était pas un problème mais que les deux formats de paquets ne sont pas l'origine du problème. Si c'était le cas, alien résoudrait tous les problèmes et les RPM fedora marcheraient sans problème sur Suse.
« 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: J'essaye de me soigner
Posté par zurvan . Évalué à 1.
oui mais non : chacun a des sensibilités différentes, et il est difficile de contenter tout le monde. Systemd est symptômatique de cela : une partie des gens va adorer, une autre partie détester, et c'est pas plus mal d'avoir des alternatives si certains se mettent à déconner et rendent le bureau inutilisable (cas de gnome3, selon certains, dont je fais partie).
On peut étendre ça aux bureaux proprio et commerciaux : windows 8 ne semble pas faire l'unanimité, n'en déplaise aux "power users" windows qui ne jurent que par windows XP.
Quant à Mac OS X, l'interface est plutôt jolie, la gestion matérielle (mise en veille etc) fonctionne bien (encore heureux), mais parfois c'est pas la joie. De ce que j'ai vu (j'ai utilisé mac os x au quotidien il y a quelques années), le finder est plutôt mal fichu (si ma mémoire est bonne on ne pouvait pas faire de "couper, coller" de fichiers, entre autres limitations, heureusement ils n'ont pas supprimé la commande
mv), les iapps bancales et bien verrouillées, bref mon portable et pc de bureaux fonctionnent bien avec Linux (y compris la mise en veille) et KDE (et ça me laisse aussi la possibilité d'y accéder en mode terminal ou avec un gestionnaire de fenêtre allégé type openbox)Après c'est sûr que la création de paquets c'est pas toujours la joie. J'aimais bien le système de description pour les PKGBUILD, faudrait voir du côté de pkgsrc si c'est similaire (mais c'est pas trivial à installer le système sous linux)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: J'essaye de me soigner
Posté par ariasuni . Évalué à 2.
Il va falloir qu’il pensent à la retraite alors… Ah bah finalement, non.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: J'essaye de me soigner
Posté par groumly . Évalué à 2.
Sisi, un drag'n'drop tout con.
Par contre yavait pas de raccourci clavier pour ca jusqu'a mavericks.
Honnetement, en 10 ans de macosx, ca m'a jamais manque, au point que j'ai pas compris ce qu'ils voulaient dire quand ils l'ont annonce l'annee derniere.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: J'essaye de me soigner
Posté par reynum (site web personnel) . Évalué à 7.
J'essaye de me soigner, et arrêter d'essayer d'expliquer que ça me pose problème, de toutes façon les gens ne veulent pas m'écouter.
ça correspond plus au ton Caliméro de ton commentaire, tout en étant plus proche de la vérité.
kentoc'h mervel eget bezan saotred
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: J'essaye de me soigner
Posté par freem . Évalué à -2.
Merci pour la leçon de latin, je ne connaissais pas ce mot ( même pas ironique mon remerciement ).
Mais je pense que tu pourrais être tolérant et juste corriger d'un, si je ne me trompe pas: "s/<sic>/sigh/g"
[^] # Re: J'essaye de me soigner
Posté par ariasuni . Évalué à 2.
Ouais mais c’est de l’anglais ça. En français on peut dire soupir je pense.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: J'essaye de me soigner
Posté par freem . Évalué à 0.
Sauf que soupir n'est pas une onomatopée.
[^] # Re: J'essaye de me soigner
Posté par ariasuni . Évalué à 5.
Sigh non plus, c’est une interjection (en tout cas le mot est répertorié comme tel sur le Wiktionnaire là où «pff» est décrit comme étant une onomatopée).
En effet, quand on soupire, on ne fait pas «sigh».
Écrit en Bépo selon l’orthographe de 1990
# Un petit exemple
Posté par Adrien . Évalué à 10.
Prenons un exemple : Debian et Ubuntu. Ce dernier récupère automatique environ 70% des paquets du premier, ils utilisent le même système de paquet, etc.
Mais pourquoi ne pas récupérer 100% des paquets ?? Parce que ça ferait au final une Debian, et pas une Ubuntu. Chaque distribution possèdes une ligne de conduite, une politique, et elles sont différentes l'une de l'autre. Donc Ubuntu va parfois packager différemment les choses que Debian.
L'outil n'est là que pour servir le but de la distribution. Si Debian trouve que rpm répond mieux au besoin que apt, ils utiliserons rpm.
Si tu veux uniformiser, alors il faut que toutes les distributions n'aient qu'un seul et unique but. Là on aura une distribution unique, pour les gouverner tous (
avec apt)PS : c'est triste ton avis sur les packageurs. Ils servent par exemple à palier les développeurs pourris, qui cassent tout sans arrêt, qui se fiche royalement des licences… ou qui fournissent des trucs infâment à installer (et donc à packager). S'ils ont le temps, ils peuvent aussi servir à trier les bugs des utilisateurs ou fournir un « support utilisateur », pour décharger les développeurs… Bref, ils fournissent une interface intéressante entre l'utilisateur et le développeur.
Perso en tant que packageur quand je vois le développement upstream de certains logiciels libres très connus je pleure. On passe des heures et des heures à cause de conneries qui ne devrait pas exister.
[^] # Re: Un petit exemple
Posté par coid . Évalué à -3.
En quoi le but des distributions devrait importer aux utilisateurs ?
Je constate que le choix vanté par les Linuxiens consiste à choisir une distribution. Ensuite, c’est la distribution qui choisit pour toi. Alors, certes, tu peux essayer d’outrepasser les choix de la distribution, mais que d’ennuis, que de problèmes, que de bugs…
[^] # Re: Un petit exemple
Posté par Renault (site web personnel) . Évalué à 5.
Une distribution qui vise l'usage exclusive de licences libres dans ses programmes va favoriser un certain public, celui qui va viser les débutants va avoir un jeu d'outils adaptés, une distribution avec des technologies modernes attirera certains types d'utilisateurs, etc.
Donc si, leurs buts sont importants car cela aide à l'utilisateur à choisir une distribution qui sera conforme à ses attentes.
[^] # Re: Un petit exemple
Posté par coid . Évalué à 2. Dernière modification le 06 juin 2014 à 10:00.
En quoi ceci nécessite-t-il un système de paquets différent du voisin ?
En quoi ceci nécessite-t-il un système de paquets différent du voisin ?
En quoi ceci nécessite-t-il un système de paquets différent du voisin ?
;)
[^] # Re: Un petit exemple
Posté par Renault (site web personnel) . Évalué à 2.
Je répondais à ta question qui mettait en doute l'intérêt d'avoir des buts différents entre les distributions.
Après en effet, cela ne justifie pas ces différences.
[^] # Re: Un petit exemple
Posté par Boa Treize (site web personnel) . Évalué à 4.
Cela ne le nécessite pas, et c'est là tout l'exemple à l'origine de ce fil de discussion : Debian et Ubuntu utilisent exactement le même système de paquets, mais tu ne peux pas prendre un paquet Ubuntu au hasard et le mettre sur ta Debian, car Ubuntu fait certaines choses différemment de Debian, et le paquet ne marchera pas. (Et si Ubuntu faisait tout pareil, ça s'appellerait Debian ; inévitablement une distribution différente a au moins une incompatibilité avec une autre.)
Bref, comme dit plusieurs fois dans les commentaires de ce journal, le format du paquet n'est que l'arbre qui cache la forêt. J'ai fait pas mal de Slackbuilds, de RPM et je sais comment les Deb sont faits, le problème n'est pas l'empaquetage, mais de respecter les normes de chaque distribution : quels fichiers de configuration, quels fichiers d'init, comment gérer le 32/64 bits, et bien sûr, les dépendances. Bien sûr, on peut travailler à minimiser ces écarts (systemd vaincra ?), mais il y en aura forcément toujours.
[^] # Re: Un petit exemple
Posté par coid . Évalué à 0.
C’est bien que ce que j’entendais par «système de paquets» : administration et dépendances.
[^] # Re: Un petit exemple
Posté par Patrick Nicolas . Évalué à 3.
Une distribution dont le but est de rester la plus simple possible (Arch) ne va pas utiliser les scripts complexes pour mettre à jour la configuration, c'est laissé à l'utilisateur.
Une distribution dont le but est de permettre de tout choisir (Gentoo) ne peut pas fournir uniquement des paquets compilés, et les paquets sources doivent laisser la possibilité de configurer.
Il y a probablement d'autre usages qui nécessitent une configuration supplémentaire pour des questions de sécurité, pour des installations par utilisateur ou des besoins auxquels je ne pense pas.
On a donc déjà au moins une bonne raison d'avoir des formats de paquets différents, et comme ça a été déjà dit le contenu dépendra de la politique de la distribution.
[^] # Re: Un petit exemple
Posté par ariasuni . Évalué à 2.
Utiliser des .deb ou des .rpm n’oblige pas à écrire des scripts compliqués pour l’installation ou la désinstallation d’un logiciel.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Un petit exemple
Posté par barmic . Évalué à 4.
AMHA le problème est différent. Arch ne veux pas faire de chose complexe lui-même et les formats de paquets classiques (en tout cas deb) ont perdu de vu une qualité assez essentielle « les choses simples doivent rester simples ». Le fait de vouloir faire quelque chose de simple ou non n'oblige pas à utiliser des formats différents, c'est juste que les deb (et les rpm dans une certaines mesures) sont trop complexes pour ça, on y a ajouter un maximum de contraintes et le packaging est compliqué même quand tu veut faire quelque chose de simple (mais ça n'est pas une fatalité).
Les .deb le permettre via
apt-buildça n'est pas très compliqué à faire.La bonne raison c'est ne pas avoir envie d'améliorer l'existant, c'est ça ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un petit exemple
Posté par Adrien . Évalué à 1.
Pourrais-tu montrer en quoi les deb sont trop complexes ?
[^] # Re: Un petit exemple
Posté par barmic . Évalué à 3.
Les formats de fichiers de descriptions fragiles ? (sensibles à l'indentation, demandant des choses saugrenues comme des lignes constitué d'espaces suivi d'un ., basé en partie sur de la convention,…)
L'utilisation de Makefile à un endroit où on n'utilise genre pas du tout les mécanismes de make ? (gestion de dépendances entre les tâches, parallélisation des tâches, simplification d'écriture via l'utilisation de régles connues)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un petit exemple
Posté par Adrien . Évalué à 2.
tu parles probablement du debian/control. Effectivement il faut respecter la syntaxe… c'est si difficile que ça pour un développeur ? Et puis faut pas déconner, pour faire un paquet simple, la syntaxe c'est vraiment pas la mort.
Ah ? un Makefile ne sert pas à construire et installer un programme ?? Je suis d'accord pour dire que la syntaxe du Makefile est pourrie à chiée, mais l'histoire est là.
Mais heureusement il y a des outils pour simplifier tout ça, au hasard debhelper, qui réduit le makefile à :
Je persiste à penser que faire un paquet Debian simple c'est faisable facilement et simplement. Perso je fais des paquets Debian pour faciliter les mises à jour de gros logiciel non libre, ça passe très très bien.
[^] # Re: Un petit exemple
Posté par barmic . Évalué à 5.
On peut dire la même chose pour code en whitespace. Utiliser un format qui utilise pose des contraintes qui n'ont pas lieu d'être ou basées sur des caractère généralement non représentés ou représéenté par un ou plusieurs blanc, c'est pas quelque chose de génial.
Construire des programmes si, c'est pour ça qu'il est conçu. Installer des programmes non, des gens s'en servent pour peut être mais non il n'est pas fait pour installer des programmes il le fait uniquement parce qu'il est turing complet. Makefile c'est un langage à dépendance si ce que tu as à faire n'est pas modélisé sous cette forme alors utiliser make se rapproche du gros hack. On pourrait imaginer faire une installation ainsi :
Mais ce n'est pas comme ça que c'est fait.
Là au moins on sait tout de suite ce que ça fait…
La multiplication des debian-helper me fait dire qu'il faut tout de même beaucoup d'aide pour faire quelque chose de "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: Un petit exemple
Posté par Renault (site web personnel) . Évalué à 3.
Rien à voir avec Turing Complet.
Turing Complet est plus une propriété mathématique qui confère à tout langage possédant certaines instructions de pouvoir exécuter n'importe quel algorithme.
Cependant, Turing Complet n'étant qu'une propriété formelle, elle ne traite les histoires d'ordinateurs, d'entrées/sorties, dialogues entre programmes et son environnement, etc.
Typiquement Brainfuck et Whitespace sont des langages Turing Complet mais il te sera difficile de concevoir un pilote de périphérique avec (pas d'Assembleur inline, pas forcément de dialogue poussée avec l'OS, gestion des fichiers et autres entrées/sortie).
Donc make peut le faire, mais pas uniquement grâce à ça.
[^] # Re: Un petit exemple
Posté par flan (site web personnel) . Évalué à 1.
Accessoirement, c'est du tar.gz (bon, ça va, y a des libs dans tous les langages) encapsulé dans du .ar (c'est déjà plus « rare », malheureusement).
Cela dit, les .rpm sont des .tar.gz encapsulés dans du cpio, ce n'est pas non plus évident de trouver des libs dans chaque langage pour gérer ça…
[^] # Re: Un petit exemple
Posté par vv222 (site web personnel) . Évalué à 1.
Sauf confusion de ma part, par défaut c'est maintenant la compression xz qui est utilisée au lieu de gz. (c'est en tous cas le comportement de dpkg-deb)
Ça n'apporte pas grand chose au débat, mais je reste un pinailleur dans l'âme ;)
[^] # Re: Un petit exemple
Posté par Patrick Nicolas . Évalué à 3.
apt-build permet de choisir les options passées au configure ? Il permet de définir les dépendances en fonction de ces options de configuration ? Il permet de gérer les paquets à recompiler en cas de changement d'ABI ?
Je ne pense pas que ce soit possible, ni souhaitable d'ailleurs pour garder la cohérence de Debian. Les fonctionnalités avancées de Gentoo demandent une gestion très différente du système et donc un contenu tout autre dans les paquets.
[^] # Re: Un petit exemple
Posté par barmic . Évalué à 3.
Je ne suis jamais allais si loin, mais tu peut de toute manière toujours refaire ça avec
apt-get source.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un petit exemple
Posté par Adrien . Évalué à 3.
Si l'utilisateur ne veut pas utiliser une distribution, il peut faire sans… ou créer sa propre distribution. Rien n'est imposer, les distributions proposent des choses, l'utilisateurs fait ensuite son choix.
En pratique sous Linux l'immense majorité des gens préfèrent utiliser une distribution qui pré-mache le boulot. Et comme tous les gens n'ont pas les mêmes besoins certains utilisent Ubuntu, d'autres Debian, d'autre RHEL, Archlinux, etc.
[^] # Re: Un petit exemple
Posté par j-c_32 . Évalué à 2.
C'est plutôt l'inverse, non ?
Ubuntu a été créé parce que les utilisateurs voulaient une distribution plus "user friendly", ArchLinux a été créé parce que les utilisateurs voulaient une distribution "à configurer soi-même facilement", …
Ensuite, le système de packaging n'a pas d'importance: si les développeurs préfèrent X à Y, c'est 100% transparent pour l'utilisateur qui utilise le logiciel de gestion de paquets.
# L'histoire
Posté par freem . Évalué à 10.
Je pense que l'une des raisons majeures, c'est l'historique.
Plusieurs distros ont fait leur format, parce que celui du voisin ne permettait pas de faire un truc qu'elles voulaient absolument ( non, je n'ai pas d'exemple, dans le monde linux, je suis bien trop jeune. Ceci dit, je suis un programmeur, donc je peux imaginer le truc d'ici. Par exemple, les paquets suggérés pouvaient ne pas exister dans un format, ou la signature numérique du mainteneur, etc ).
Depuis, les formats ont, forcément, vu que c'est libre, récupéré les fonctionnalités des autres qui leurs semblaient intéressantes ( pas nécessairement toutes, par exemple, je suis persuadé qu'un paquet gentoo permets bien plus de souplesse qu'un deb au niveau des dépendances ).
Mais parallèlement, les outils manipulant ces formats ont évolué, eux aussi, les distros se sont bâties sur ces outils complexes ( bah oui, résoudre des dépendances, et trouver des solutions optimales automatiquement, ce n'est pas quelque chose de simple, surtout quand une demande de l'utilisateur casse un autre paquet. Dans ce genre de cas, aptitude par exemple, proposera plusieurs solutions ) et donc migrer vers le format du voisin serait inutilement coûteux et complexe.
Après, même si les paquets binaires sont probablement très semblables en terme de nombre de fonctionnalités, je ne crois pas que ce soit le cas avec les distros source, non plus.
Donc, même si je suis prêt à admettre que c'est un problème, je pense également que le remédier est hyper complexe sinon impossible, l'humain derrière la machine étant un appareil dont il est difficile de prévoir le comportement ou de l'orienter, à plus forte raison quand on prône la liberté.
Et puis, franchement, il faudrait arrêter de dire que c'est compliqué de faire un paquet… dans le cas de Debian ( je ne connais que ça, navré, mais à ce que je peux lire un peu partout ça semble le format le plus pénible? ) par exemple, il suffit de recréer l'arborescence ou l'on souhaite envoyer les fichiers, les y placer, et à la racine de cette arborescence, créer un dossier DEBIAN contenant un fichier control, ou l'on écrit les dépendances, la description, le nom du mainteneur, l'architecture cible, etc.
Une fois tout ça fait, on remonte d'un dossier, et on tape: dpkg-deb -b
C'est pas complet ( pas de hash pour l'intégrité des données, notamment, parce que pour ça, il faut un autre fichier avec les hash de chaque fichier. Je n'ai pas encore regardé comment ça marche, mais ça ne doit pas casser 3 pattes à un canard… ), et ça ne sera jamais intégré tel que dans Debian bien sûr, mais ça marche et c'est bien plus propre que du "./configure && make && sudo make install".
Maintenant, le but du développeur ne devrait pas nécessairement être l'intégration dans une distribution, mais que le logiciel soit utilisable facilement, quitte à lui demander d'ajouter un dépôt s'il veut des MaJ automatiques ( et puisqu'on compare avec la concurrence, je rappelle que la concurrence ne fait que commencer à s'y mettre, aux MaJ auto des softs installés… ) chose qui n'est même pas obligatoire: pas besoin du dépôt complet pour double cliquer sur le .deb ( ou lancer un dpkg -i, mais c'est juste parce que moi, je n'ai pas d'explorateur de fichiers. )
Après, c'est sûr, je ne connais que Debian, et en conséquent, je ne fais les paquets de mes outils que pour Debian. En même temps, les gens qui font des outils pour windows, quand ils acceptent de fournir un installateur, ne le fournissent pas pour Mac OS… et je considère que deux distributions sont des systèmes d'exploitation différents ( même si c'est techniquement inexact ).
Ce qui ne m'empêchera jamais d'accepter un script pour bâtir un rpm, si quelqu'un m'en fournit un.
Dernière phrase qui me permets de rappeler ce principe élémentaire du libre:
Les développeurs sont libres d'améliorer leurs logiciels, mais les utilisateurs sont aussi libres d'y contribuer. Dans les deux cas, les gens ont le choix de faire ou de ne pas faire, mais je trouve malhonnête ce genre de phrases:
La documentation, c'est plus censé être le boulot des développeurs, d'une part, sauf que ça les ( nous? ) fait chier, profondément. Les intégrateurs, ou packageurs, sont censés utiliser cette doc pour fournir un mécanisme d'installation propre pour un système donné.
Bref.
Et toi, qui affirme relativement fièrement que ça te fait chier de "perdre ton temps" à contribuer, comment peux-tu dire ce que les autres devraient faire, si tu ne mets pas la main à la pâte? Yakafokon? Ou alors peut-être contribues-tu, et dans ce cas, peut-être serait-il plus constructif de nous dire quels problèmes exacts tu as rencontré, parce que je n'ai vu aucun problème concret dans ton journal ( bien que je sais qu'il en existe, ce serait stupide de le nier, mais c'est toujours mieux un argumentaire avec de vrais morceaux d'arguments bien formés dedans )
[^] # Re: L'histoire
Posté par julmx . Évalué à 2.
Je ne dis pas pas que ça me fais chier de contribuer en général, juste de faire des paquets pour telle distribution. Après tu as raison dans le sens ou je suis bien content d'utiliser les paquets que les autres ont fait.
Je pars justement d'un cas concret dans ce journal : celui de Newebe, typiquement, ce genre de projet qui est porté par peu de développeurs avec beaucoup de boulot a faire. Une installation facile permet d'avoir plus d'utilisateurs, plus de remonté de bugs, plus de contributeurs potentiels, etc…
Seulement voila, il faut faire un paquet ci, ou ça, un ppa, une paquet aur, un playbook ansible, … etc
Ça prend un temps fou !
Pour clarifier, l'idée c'est pas qu'il existe un seul paquet apache ou firefox dans le monde linux, chaque distribution peut bien patcher comme elle veut sur ces dépôts, si ça rempli ces objectifs. Je pense plutôt aux développeurs dont l'application n'est pas assez populaire pour que les distributions se chargent de faire le boulot. Rendre son appli accessible aux linuxiens facilement est une vrai prise de tète.
En gros je rêve que les AUR de arch soient utilisables un peu partout.
[^] # Re: L'histoire
Posté par freem . Évalué à 1.
Hum… archives auto-extractible, compilation statique. Un peu comme ce que fait NVidia avec ses pilotes, sauf qu'il est possible de faire moins complexe ( pas de besoin de compilation, après tout ).
Et pour certains langages ( ruby notamment ), tu as même des package manager dédié au langage. Comment ça communique avec le système par contre, aucune idée.
Sinon, je pense qu'un dev qui fait les packages uniquement pour sa distro, sans envoyer chier les contributeurs potentiels qui soumettrons des paquets pour leurs distros, se prend pas la tête et à un truc simple à installer pour les utilisateurs. A fortiori s'il utilise l'une des distros qui servent de base à la plupart, c'est à dire debian ou fedora ( je suppose imaginairement que c'est Debian, mais manquant de chiffres… ).
D'ailleurs, quelqu'un qui connaît ( mieux que moi ce serait pas dur, et me suis jamais penché sur cette option ) Debian saurait probablement automatiser le build à partir des sources, il semblerait que c'est ce qu'ils font dans le repo officiel. Donc, il y aurait moyen de faire un paquet source pour toutes les filles de Debian automatiquement ( cross compilation, VMs, etc. )
[^] # Re: L'histoire
Posté par claudex . Évalué à 4.
C'est ce que fait l'opensuse build service. Un deb source pour Debian 6 et 7 et Ubuntu de 10.04 à 14.04.
« 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
# En pratique
Posté par j-c_32 . Évalué à 2.
Une question reliée à ça: en pratique, on fait comment pour avoir quelque chose d'unifié ?
Comme dit par ailleurs: le problème n'est pas le format, car un rpm pour Suse est également incompatible avec Fedora ou Mageia. La distinction "deb", "rpm" et autres n'a donc pas vraiment d'importance: avoir par exemple que des rpm ne sert à rien s'il faut quand même faire des choses spécifiques aux distributions.
Ce qu'il faudrait donc, c'est:
soit des outils de conversion. Ça existe déjà pour les différents formats (par exemple: alien), donc, si on pense que c'est la solution, c'est qu'on considère que la situation actuelle est déjà résolue.
soit une organisation au dessus des distributions. Cela me parait peu réaliste:
si je suis packager pour, par exemple, Suse, je vais donc devoir systématiquement contacter les types de Fedora, Debian, Ubuntu, ArchLinux, … chaque fois que je fais un paquet et organiser une réunion pour décider de ce qui est le mieux (avec des solutions qui peuvent sembler parfaite pour une distribution tout en étant mauvaise pour une autre).
Bref, ce sera un beau générateur de flamewar: "les méchants de chez Bidule ont poussé pour que le paquet X soit divisé en deux, ce qui est inutile pour nous et rend le système trop compliqué pour les utilisateurs", "on voit bien que Roger impose son logiciel en prétendant que ça doit être une dépendance pour le paquet Y alors que le paquet Y pourrait être décomposer en Y1 et Y2 pour que Y1 ne nécessite pas le logiciel de Roger", … et évidemment les dizaines de réactions sur les blogs et linuxfr "le problème avec Linux, c'est que les bonnes solutions sont étouffées par des règles qui ne servent à rien, et ça perturbe les utilisateurs et ça donne une mauvaise image de Linux".
Bref, je ne comprends pas en quoi le problème actuel est suffisamment gênant pour nécessiter une solution aussi problématique.
[^] # Re: En pratique
Posté par claudex . Évalué à 3.
Il y a deux types de problèmes. Ceux qui sont sur une distribution et qui sont en manque de paquets, pour ça, je ne vois pas de solution facile. Et les développeurs qui veulent fournir leur logiciel au plus grand nombre, pour ceux-là, il faut se farcir les différentes distributions et faire un paquet pour chacune. La solution pour eux, c'est quelque chose du genre de ce que j'ai décrit dans un autre commentaire.
« 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: En pratique
Posté par benoar . Évalué à 2.
Il y a un truc fait par le projet GNU qui existe depuis longtemps qui s'appelle les autotools et qui fait ça « très bien » depuis des lustres. Faire un .deb depuis un projet autotoolifié c'est très peu de boulot. Après, chacun a sa manière de haïr les autotools, mais bon… et aussi, n-ième standard, toussa…
[^] # Re: En pratique
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Les autotools ça n'est utile que pour du C/C++ sous linux, non? On fait comment si on utilise un autre langage et qu'on vise d'autres OS?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: En pratique
Posté par freem . Évalué à 0.
cmake?
[^] # Re: En pratique
Posté par benoar . Évalué à 1.
Non, ça gère plus que ça (j'ai des projets en shell avec autotools), et à priori, ça marche sur un paquet de plateformes (au moins OSX et BSD), même si pour Windows, c'est peut-être pas l'idéal car il faut MinGW.
# Mauvais problème
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 5.
Pour avoir été mainteneur, je pense que le problème n'en est pas un.
Ce qui est vraiment problématique, c'est que beaucoup de logiciels ne sont pas trivialement portables, ce qui rend leur empaquetage compliqué. S'ils était tous bien codés, alors il serait facile de les empaqueter, et le choix des outils serait purement subjectif.
En fait, ce qu'il faut, c'est que les archives soient indépendantes de la distro. Il serait bien que la même archive installe son contenu à des endroits différents en fonction de l'OS/la distribution. Ainsi par exemple, les executables sur Debian iraient dans /usr/bin, et sur FreeBSD, dans /usr/local/bin. Le chemin ne serait pas dans l'archive, qui contiendrait à la place une méta-donnée "executables publiques" (ie, qui iraient dans un /bin habituellement dans le path).
[^] # Re: Mauvais problème
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
On peut aussi renverser le problème: les problèmes viennent souvent de systèmes de packaging inutilement compliqués, mal documentés et pas à jour (on dirait que la plupart ignore qu'en 2014, on développe avec autre chose que gcc et make).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Solution simple et immédiate
Posté par Maclag . Évalué à 10.
Que tout le monde passe à Debian une fois pour toute et on sera tranquilles!
Pour les autres distros, merci de vous baser sur Debian. Vous pouvez modifier certains paquets à condition de ne pas rendre les paquets tiers incompatibles.
Et voilà!
Ah, au fait, je me mets une fois de plus consultant sur le coup, et donc je vais vous demander 15000€ pour l'étude complète et la solution clé en main.
Plus sérieusement, ça finira soit jamais, soit comme pour le système d'init qui n'était un problème pour personne sauf ceux qui doivent bosser avec: quelqu'un finira par poser une solution sur la table qui aura des mérites techniques indéniables, et ça passera dans toutes les autres distros progressivement, et parfois très douloureusement.
Reste que même si on se met d'accord sur le système de paquet, il ne faut pas oublier que toutes les distros n'ont pas le même environnement (je parlais de Debian, mais un paquet stable ne s'installera pas forcément sur unstable, voire peu de chances que ça marche sans faire gaffe).
Du coup, "LE" système qui s'imposera viendra avec une tripatouillée de contraintes qui permettront une génération simple du paquet (emplacements des répertoires ou au moins variables d'environnement standardisées pour les indiquer, etc.). Ça permettra de troller encore plus longtemps.
N'oublions pas non plus que si la solution vient de RH, ce sera forcément un complot.
Et pour mettre les 2 pieds dans le plat: en tant qu'utilisateur Debian, je me contrefous de savoir si Debian garde les deb ou passe aux rpm, tant que ça juste marche sans se vautrer, comme maintenant quoi!
[^] # Re: Solution simple et immédiate
Posté par Le Gab . Évalué à 0.
Tu as volé 10% de mon prochain post! =)
Je pense que Debian doit pousser le marketing, elle est quasi irréprochable pour le desktop depuis la version 6. J'utilise Gnome Shell et pas d'ion3 ou xrazormonad, hein.
Ça ce n'est pas très grave et même mieux comme conteneur, par contre je suis moins intéressé par le moteur yum.
Sinon, je trouve l'approche d'Ubuntu intéressante, certes moins libres dans la marge de manœuvre, le côté on fourni un SDK et donc un référentiel et une suite d'outil pour développer pour cette plateforme. Car comme il a été fait remarqué plus haut la partie portabilité ou intégration est le truc qui fait le plus chier les programmeurs.
[^] # Re: Solution simple et immédiate
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
La config est graphique ? A l'époque tout devait se faire dans des fichiers de configuration cryptique. C'était une facilité énorme de mandrake/mandriva/mageia.
"La première sécurité est la liberté"
[^] # Re: Solution simple et immédiate
Posté par Maclag . Évalué à 4.
Oui, j'allais dire depuis un bon bout de temps déjà, sauf que je ne sais pas traduire "un bon bout de temps" en nombre de versions stables, et chez Debian, ça peut vouloir dire 1…
M'enfin l'essentiel est que oui, maintenant on peut avoir une install graphique.
Par contre, vu de ma fenêtre, l'install graphique idéale grand public, c'est celle qui ne pose pas d'autre question que "je fais ça, ça te va? (si tu ne sais pas, clique sur oui") avec des questions du niveau "Tu habites en France et tu veux un système en Français. Oui ou non?".
[^] # Re: Solution simple et immédiate
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est en gros, ce que fait mageia.
"La première sécurité est la liberté"
[^] # Re: Solution simple et immédiate
Posté par freem . Évalué à 2.
En même temps, c'est le cas. Avec Debian, les questions que l'install te pose ont des valeurs par défaut tout à fait acceptables, pour un non bidouilleur ( même si c'est un peu contraire à l'esprit de la communauté au final, puisque j'ai l'impression que les gens sur la ml sont quand même du genre à bricoler leur distro ).
La seul réelle question posée, c'est la langue, et ça, ça risque pas de changer, et pour cause: il n'y à aucun moyen de deviner la langue de l'utilisateur sans réseau, et le réseau est configuré après la langue et le clavier. Et même deviner la langue via le réseau, je crois que Debian n'apprécie pas ( me semble avoir vue la question posée à une époque ) pour des problématiques de sécurité ( accès réseau sans demander? ) et de fiabilité ( qui me dit que je ne dois pas passer par un proxy, qui fausserai potentiellement les données? Et si je suis à l'étranger? ).
Pour moi, Debian fait déjà ce que tu demandes. On pourrait juste regretter que le choix par défaut ne soit pas le mode simpliste ( il en existe un, qui ne pose quasi aucune question ) mais comme je l'ai dis, j'ai l'impression que c'est un peu contraire à l'esprit de la communauté Debian, même si elle est toujours prête à aider même les gens avec le moins de connaissance.
[^] # Re: Solution simple et immédiate
Posté par claudex . Évalué à 3.
Et si je suis dans le pays mais qu'il y a plusieurs langues ? Genre en Belgique, en Suisse, aux USA (où 12% de la population parle espagnol)
« 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: Solution simple et immédiate
Posté par Le Gab . Évalué à 0.
OK, restons sous Wind… ah mais lui aussi il ne fait pas ça, ben Mac, lui le fait parce que les Mac sont régionalisés.
Sinon, pourriez-vous trouver de réelles problématiques ou alors vous voulez vraiment pas qu'on propose Linux en fait.
[^] # Re: Solution simple et immédiate
Posté par Maclag . Évalué à 4.
Je ne pense pas qu'il se plaignait de Linux, Debian ou les questions, je pense qu'il alimentait la justification du pourquoi les questions de localisation et langue ne peuvent pas être évitées à l'installation.
[^] # Re: Solution simple et immédiate
Posté par claudex . Évalué à 3.
Tout à fait.
« 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: Solution simple et immédiate
Posté par Funigtor (site web personnel) . Évalué à 1.
Un Mac te demande la langue à utiliser dans tous les cas.
[^] # Re: Solution simple et immédiate
Posté par Le Gab . Évalué à 0.
Ben c'est parfait ça. il n'y a plus de problème, on peut proposer Debian pour le Desktop.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.