Spyhawk a écrit 1154 commentaires

Je me souviens d'une phrase qui dit un truc de ce genre:
Un logiciel n'est pas parfait quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à enlever.

La citation originale et l'auteur sont:

"La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever" - Antoine de Saint-Exupéry GNOME Team

C'est gentil, mais il y a à mon avis un paquets de cas d'usage différent et ce n'est pas en créant un ou 2 paquet qu'on peut juger.

J'en ai vu assez pour me rendre compte que créer un rpm pour des paquets relativement simples est bien plus compliqué dans le cas de .deb, alors j'ose pas imaginer pour les cas plus complexes. Aussi, j'ai bien spécifié "Pour moi", ce qui veut dire que c'est un avis personnel, moi qui fait du packaging une fois tous les 6 mois.

De plus un paquet, c'est bien mais il faut voir comment se passe la mise à jour de celui-ci et l'outillage qu'il y a coté utilisateur pour gérer les paquets (comme presto ajouté à yum).

Je parle spécifiquement des formats .deb et .rpm, qui ont été créé spécifiquement pour la gestion des dépendances (et pas leur résolution). Les différents Yum, Zypper, URPMI, Apt-get et autre aptitude n'ont rien à voir ici, c'est un tout autre sujet.

Si tu pense que la facilité de créer un paquet vite fait est la seule chose intéressante, je pense que tu devrais t'inscrire à la ML de la LSB pour leur dire d'aller voir du coté des paquets Arch qui mettent une claque autant aux .deb qu'aux .rpm du point de vu de la facilité.

Remet les choses dans le contexte avant de sauter sur tes grand chevaux: la LSB prédate les PKGBUILDs d'Arch Linux, ensuite y'a aussi une question de popularité de format à l'époque (et je suis le premier à penser que PKGBUILD est globalement supérieur à RPM/Deb).

Cependant, j'ai lu à plusieurs reprise ce point précis: deb à été créé plusieurs années avant rpm

C'est surtout pas exactement vrai, relève d'une légère déformation de la vérité et mérite un petit éclaircissement. Le .deb, dans sa forme primitive, apparaît en 1994 pour s'établir dans sa forme actuelle dès 1995 (la première Debian est délivrée l'année suivante). Le RPM quand à lui, apparaît en 1997 mais est découle directement des expériences acquises avec le système RPP (le RPM primitif) qui était en usage chez Red Hat déjà avant la sortie de RH 2.0 en 1995, ainsi que de PMS de la distribution Bogus délivrée en 1994.

Alors oui, si on regarde les formats dans leur format actuels (minus les évolutions mineures), .deb est apparut en 1995 et RPM en 1997. Mais en regardant de plus près, on peut juste dire que ce sont deux formats incomplets qui ont évolué en parallèle dès 1994 (et hop les debianneux peuvent ravaler leur légende urbaine :P)

Mais je n'ai jamais vu la moindre raison technique ( oui, je sais, on est lundi, pas trolldi… ) expliquant cette raison.
Donc, ma question est simple: y a t-il une seule raison objective ayant permis d'élire rpm comme format universel?

Ben écoute, hein, .rpm et .deb sont peu être similaire à l'usage, mais t'a qu'à t'essayer au packaging pour ces 2 formats et après tu tires tes propres conclusions sur lequel des deux a le plus d'argument pour avoir la vocation d'être utilisé partout. Pour moi c'est très clair, les types de la LSB ont fait le meilleur choix.

Gentoo supporte systemd officiellement (c'est juste pas l'init par défaut).

Dit autrement, si tout le monde passait au vrai format (c’est-à-dire deb) est-ce que cela simplifierait vraiment le boulot ou de toutes façons les différences entre distributions nécessiteraient quand même de bosser ?

Utiliser une ferme de compilation comme l'OBS réduit considérablement les soucis de chemin, nom et version de lib. Le souci à mon avis, c'est plutôt d'écrire le fichier .spec (ou l'équivalent pour .deb) initial. Et là, pour m'être essayé au packaging pour différentes distributions, je peux sans appel dire que RPMs n'est pas optimal tant il y a de petites différences entre les RPM Fedora et openSUSE, mais ça reste largement moins ennuyant et moins compliqué que de créer des .deb dont la création des divers fichiers (control/rules/dsc/…, sérieusement?) me fait penser à un parcours du combattant, en pleine jungle et par 20 mètres de fond.

Mais de toute façon, on sait tous que le vrai format n'est ni .deb ni RPM, mais tar.xz :P

Sens unique? Un développeur qui accepte un patch dans sa branche principale s'engage à maintenir le patch toute la vie du projet.

Encore heureux! Manquerai plus qu'il s'approprie le copyright du code et oblige le contributeur à le maintenir à jamais…

Disons que upstart n'a jamais été très ouvert aux contributions extérieures, ce qui a incité à la création d'une alternative.

Si si, justement. C'est juste que c'est à sens unique, comme mentionné dans ton premier lien:

A CLA is just an employment without a wage.

Avec Upstart qui ne sera supporté officiellement pas plus aucune distribution majeure (et mourir gentiment de sa belle mort), je pense qu'OpenRC va devenir, de facto, l'init des autres noyaux Debian en plus d'être supporté par Gentoo (l'autre alternative étant sysV que personne ne regrettera).

Je crois que dans le modèle Suisse, il y a une votation toutes les semaines.

Faut pas exagérer :)

On s'arrange pour regrouper les votations lors d'une même période. De fait, on ne vote "que" 3 ou 4 fois par an, et à chaque fois sur plusieurs sujets. Prochain scrutin fédéral agencé à la mi-Mai.

Le faible taux d'abstention s'explique avant tout par un désintéret de la question politique, parce que les sujets sont pas toujours très intéressants (on peut aussi voter par correspondance, donc y'a pas besoin de ne pas partir en week end non plus).

Tous les membres du comité se fichent d'OpenRC (pour le noyau Linux).

Il est d'ailleurs clair que les plus manipulateurs si on regarde le vote ce sont ceux qui ont mis F en dernier… Alors que s'ils veulent remplacer V, la discussion devrait être prioritaire sur V.

C'est clairement faux. Après 5 (cinq!) mois de discussion, pour l'init par défaut, et uniquement pour le noyeau Linux, y'en a quelques un qui ont estimé qu'avoir une décision (même le status quo) est plus important que de discuter encore 5 mois supplémentaires. Y'a qu'à voir la menace en privé d'une GR si la décision ne tombait pas "dans un très court délai".

C'est d'ailleurs pour ca que Colin Watson (employé Canonical) a voté "U D .. F ..", en sachant que ca donnerait systemd gagnant. Systemd n'a pas sa préférence, mais le cirque a assez duré et il est temps de se poser les autres questions importantes.

Non, il suffit seulement de voter F avant D (on est dans un système de Condorcet). C'est exactement ce qui s'est passé lors du premier vote (4-4, mais F globalement avant/équivalent à D, donc le vote supplémentaire de Bdale ne servait à rien).

Voter 'F' (Further discussion) est un moyen de contourner l'avantage du double vote du président de comité en cas d'égalité, qui ne s'applique pas contre l'option par défaut (F, justement).

C'est un simple blocage de la part des pro-upstart (voir le journal Debian-systemd précédent, lien dans mon commentaire plus bas).

Le journal précédent sur Debian et systemd est celui-ci.

Mais sinon, effectivement le vote n'a défini que l'init par défaut pour le noyau Linux (après 5 mois de discussion), donc on a encore de beaux trolls devant nous.

C'est pas vraiment une question d'architecture, mais de noyaux. Au contraire de toutes les distributions Linux majeures, les paquets Debian peuvent être utilisés avec Hurd ou kFreebsd.

Un deuxième init devra donc être supporté officiellement (et je ne sais pas ce que le terme "officiellement" implique réellement: obliger les mainteneurs à inclure des scripts Upstart/OpenRC dans tous les paquets qui ont besoin d'un script init?).

Perso, je trouve que "doubler" la charge de travail de tous les mainteneurs juste pour le support de noyaux utilisés par 0.1% des machines Debian n'en vaut clairement pas la chandelle, d'autant plus qu'une vrai distrib BSD est probablement plus appropriée (quand au Hurd… hem… ). Mais bon, c'est Debian, ils font ce qu'ils veulent. Faut juste pas s'étonner d'être "chroniquement débordé".

Je comprends en effet qu'on puisse trouver le CLA gênant, mais soyons sérieux 5 minutes : ça n'a rien de rédhibitoire.
Ça n'a pas empêché Upstart d'être le système d'init par défaut de distros comme RedHat, Fedora ou Suse avant l'arrivée de systemd.

1/. Upstart n'a jamais été l'init par défaut dans une version de SUSE/openSUSE stable.
2/. Certains développeurs sont prêts à signer le CLA de Canonical, mais certainement pas tous, et encore moins ceux d'une distribution formée principalement de bénévoles.

Aussi, certains membres du comité ont jugés que qu'au final, maintenir ou patcher Upstart au sein de Debian aurait certainement fini en un fork permanent:

Diziet: because of the CLA, I believe that upstart in Debian would be a permanent fork, and take significant resources away from other key development efforts

C'est dommage, parce qu'entre choisir systemd pour Debian/Linux + un autre système d'init pour les autres noyaux vs Upstart pour tous, Upstart avait certainement un sérieux atout dans le cas Debian. Le CLA n'est certes pas réhibitoire, mais a certainement fait penché la balance du côté de systemd + un autre init.

Tu as raison, j'ai extrapolé un peu vite. Upstart à été considéré sérieusement (d'ailleurs il a été poussé dans RH) mais au final un examen plus approndi à montré que le design de fond est complètement mal foutu.

Attention, ce n'est pas parce que systemd devient l'init par défaut de Debian que systemV ne sera plus supporté officiellement (vu que systemd ne supportera jamais kfreebsd ni Hurd et qu'on ne va pas juste dire "fuck" à ses contributeurs)
C'est ce que le comité technique doit encore trancher.

Tout à fait. Au final, ce n'est pas le passage de systemd comme init par défaut qui donnera plus de boulot (ca en donnera même plutot moins), mais le support officiel de multiples systèmes d'init. Par contre, c'est pas sur non plus qu'Upstart soit maintenu officiellement aussi, OpenRC est peut être plus adapté à kFreebsd/Hurd et les patchs peuvent etre remonté upstream sans abandon du copyright.

C'est une question de point de vue, en l'occurrence Upstart existait avant systemd :-)

L'isolement d'Ubuntu n'est pas du à une question d'antériorité, mais au CLA de Canonical (c'est à ceci que mon pied de nez au dessus faisait référence, pas à Upstart directement). D'ailleurs ca a été dit par les gars de systemd mainte fois: sans CLA, systemd d'aurait pas de raison d'être et tout le monde aurait travaillé à rendre Upstart meilleur.

Bon, je me réponds à moi même:

La raison pour laquelle le premier vote (4-4) n'est pas passé est parce que les 4 membres pro-Upstart ont voté l'option F (Further discussion) avant systemd. Pour ceux qui n'ont pas suivi dans le fond de la salle, un vote Debian consiste en une liste de choix, par ordre de préférence.

Cette fois, Colin Watson a voté Upstart mais a classé systemd avant l'option "Further discussion", permettant à systemd de passer la rampe, et ceci en connaissance de cause.

I have a lot of sympathy with Ian's position here, hence my previous FD
votes; I think we do need to finish hashing this out, and it was
valuable to run the combined votes (even abortively) since the
combination certainly could have made a significant and important
difference. However, looking through the votes cast so far, I do not
see how separating them is actually going to make a discernible
difference to the outcome of either part, and so I don't feel that I can
personally justify holding things up any more for this. I also hope
that resolving this part will vent a little pressure so that we can deal
with the rest more effectively.
I vote UDOFV.

Et j'annonce la bonne nouvelle: systemd sera le système d'init par défaut dans Jessie.

Et à Canonical: HAHAHAHA!

Le vote a bien eu lieu, et systemd arrive en tête, non?

En fait, il manque toujours des votes au moment ou j'écris, avec 4 votes pour systemd, 1 pour Upstart, et les 3 manquants étant attendu comme vote Upstart. On vas obtenir une nouvelle égalité à 4-4 comme lors du premier vote, sauf retournement de situation inattendu.

Cette histoire de majorité qualifiée, c'est une instauration de dernière minute suite au résultat qui plait pas, ou c'est une vraie règle qui était claire depuis le départ?

Il semblerait qu'il y ait bel et bien une règle dans la constitution Debian, voir Section A.6.3:

Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration.

.. l'option par défaut étant "Further Discussion" (voir section A.3.3), dans la plus grande tradition Debian. Je laisse de coté les détails mathématiques, parce que j'ai du mal à caler la théorie du systeme de vote sur ce que l'on observe en pratique.

Mais si je comprends bien, le vote de Bdale fait la différence en cas d'égalité, sauf si l'égalité en question est avec l'option par défaut qui n'a pas besoin d'être votée explicitement. A mon avis, c'est complètement idiot et relève d'un immense manque de pragmatisme. Le vote du chef de comité pèse plus lourd justement pour éviter de se retrouver dans une situation de blocage (puisque le comité a un nombre pair de membres), or ceci ne s'applique pas dans la pire des situations (plus de blabla requis).

Te réjoui pas trop vite, rien n'est fait pour le moment.

Et pour développer un peu plus, il est important de prendre une décision sur le système d'init par défaut maintenant parce que le freeze de Jessi est prévu dans moins d'une année. Tout le travail d'intégration est littéralement bloqué actuellement.

Bdale pense également que le système de vote n'est pas adéquat pour résoudre plusieurs questions en une seule fois, d'ou le relancement d'un simple vote sur le système d'init (en gros, on refait le vote précédent qui avait été écourté par les pro-Upstart!). Les autres questions devront être résolues plus tard (intégration forte, faible.. ) selon lui.

A noter qu'il semble que certains DD ont "menacé" en privé les membres du comité d'un ultimatum: en cas de non résolution de la question du système d'init, ce sera une GR (résolution générale) qui tranchera. C'est qu'après 5 mois de discussion, on en est toujours au point de départ. On comprend en tout cas mieux l'origine du logo tournoyant de la distrib. Debian, quoi…

Debian, quoi…

Mais à propos de quoi puisqu'il ne lit pas l'article ?

Il a expliqué pourquoi il s'est arrêté et n'as pas poursuivi la lecture (implictement du moins), en soulignant l'argument fallacieux de l'article qui sert en outre de base à quasiment tout le reste de l'article.

En lisant ton commentaire, j'en en revanche que tu as appliqué la loi sauvage de "Zenitram = commentaire a ne pas lire", alors que son commentaire était tout a fait pertinent (comme la majorité des ses commentaires d'ailleurs, même si on est pas forcément d'accord avec lui).

Donc, je fais comme lui,

Si au moins t'était un minimum pertinent ou que tu amenais quelque chose au débat…

Vu que Bdale a un vote supplémentaire en cas d'égalité, ça peut faire pencher la balance.

Bah non, puisque l'égalité a déjà été atteinte lors du précédent-précédent vote (4.5 vs 4 avec le vote de Bdale, le vote suivant a été écourté), et il semble qu'il ne veuille pas forcer une décision controversée.

Ca finira en FD ou GR pour sûr.

Apparemment, Tipeee n'a pas encore été mentionné

Si si, ici

De rien.