Re: Problème de version et de cymbales

[Valentin Villenave]

On 5/5/20, Yoann LE BARS <address@hidden> wrote:
> je pense qu’il y a une vraie difficulté pour les développeurs, qui
> sont pourtant également des utilisateurs, à se mettre dans la
> perspective d’un utilisateur.

Je ne suis vraiment pas sûr que flatpak/snap/docker/electron/etc.
soient vraiment à un stade d’utilisation accessible au premier venu.
(En tout cas, pas plus que la distribution LilyPond-gub.)

(Et : oui, c’est un brin de mauvaise foi de juxtaposer flatpak, docker
et electron, flatpak étant quand même _un peu_ moins lourd que les
autres. Mais je fais cet amalgame pour appuyer mon argument : les
surcouches devraient être évitées lorsqu’elles ne sont pas absolument
nécessaires.)

> À l’inverse, le grand-public
> plébiscite des systèmes où les applications s’installent au moyen de
> paquets indépendants tel qu’Android.

Euh, tout dépend ce qu’on entend par "indépendant" : en un sens, le
succès du modèle "App Store" centralisé est venu confirmer (en moins
bien) ce que les distributions GNU/Linux faisaient depuis vingt ans.
Et de ce point de vue, je comprends tout à fait que beaucoup préfèrent
utiliser la version de LilyPond disponible pour leur distribution ; le
modèle flat/snap/truc s’approche en revanche plutôt (en mieux) de ce
que sont habitués à devoir faire les Windowsiens, obligés d’aller
télécharger des installeurs .exe/.msi/.dmg etc.

>       Est-ce que vraiment nous devons rejeter l’hypothèse qu’Autopackage ne
> répondait qu’imparfaitement à la demande ?

Je pense que dans le cas de LilyPond, cela faisait simplement
double-emploi avec les installeurs gub. Et ce serait également le cas
d’un truc en flatpack/snappy (avec probablement un peu de lourdeur en
plus).

>       Cependant, avec Lilypond-gub, l’application ne se mettra plus à jour
> avec le reste du système. L’utilisateur devra se tenir au courant de
> l’état d’avancement de l’application.

C’est tout à fait vrai. Ces installeurs sont destinés aux
utilisateurs/trices les plus chevronné.e.s, qui veulent avoir une
version récente pour pouvoir bénéficier de nouveautés ou de
corrections de bugs. (Et en cela, cela rejoint une large partie du
public de cette liste.)

> sur les listes de diffusions dédiées à
> LaTeX, on voit passer exactement le même discours.

Ouch. C’est quand même méchamment moins le bordel avec LilyPond ; on
distribue *un* seul programme, qui se met dans *un* seul dossier. Ce
qui me dérange infiniment moins que d’avoir à installer le machin TeX,
et puis 4000 packages perl avec ctan, et puis 25000 applications avec
pip, sans parler de npm, php compose, le machin de ruby etc. C’est
également la raison pour laquelle la proposition d’un gestionnaire de
package lilypond (lyp) a été accueillie avec un froid polaire il y a
quelques années.

Dans un monde idéal, les distributions resteraient au taquet et on
n’aurait pas besoin d’attendre trois ans que Ubuntu réalise qu’une
nouvelle version stable de LilyPond est sortie (et que _rien_ mais
alors rien n’empêche de la backporter sur tous les systèmes encore en
circulation). Ça a été le cas par le passé : ainsi, il fallait environ
3 jours pour que Fedora intégre la toute dernière version _devel_ de
LilyPond, toutes les deux semaines ; ça s’est grippé lorsque
(précisément à cause d’une déficience de gub) on a passé plusieurs
années sans publier aucune version, ni stable ni devel. Avec un peu de
chance ça peut reprendre -- mais il est certain que les petites
distributions avec peu de moyens, à moins de compter parmi leurs
contributeurs un ou deux mordus de LilyPond, ne pourront jamais rester
à la page.

> Bon, derrière, il y a déjà la question de savoir s’il est vraiment
> utile de suivre les dernières versions des applications – à titre
> personnel, déformation de débianeu, je pense que généralement non

Curieusement, quasiment personne parmi les développeurs de Lily n’est
sous Debian :-)

Pour une utilisation assez simple, il est certain qu’avoir quelques
années de retard ne pose pas de problème majeur ; la syntaxe n’a que
très peu changé depuis 2.14 (2.16 pour les fonctions en Scheme).
Encore une fois le système de publication par le site web est destiné
aux utilisateurs à qui la liste des nouveautés d’une version à l’autre
donne l’eau à la bouche, et aussi -- plus fréquemment sans doute -- à
celles et ceux qui tombent sur un bug ennuyeux et pas simple à
backporter dans la branche stable (et encore moins dans les anciennes
branches stables).

> si nous conseillons aux utilisateurs
> d’utiliser une version très récente, il faut leur fournir un moyen
> simple de conserver leur système à jour.

D’une façon générale, nous recommandons l’utilisation de la version
_stable_. Ça s’est détraqué pendant le dernier cycle car 2.18 est
devenue vraiment, vraiment ancienne au point que 2.19.83 l’a presque
remplacée, de facto, comme l’équivalent d’une version majeure.

En temps "normal", c’est-à-dire jusqu’à 2017 et depuis janvier
dernier, la seule raison pour laquelle il nous arrive effectivement de
recommander une version de développement, est lorsqu’il y a des bugs
ennuyeux et que nous préférons dire "c’est corrigé, ça va sortir dans
dix jours" plutôt que "ça va sortir dans deux ans".

> la pertinence qu’il y a à baser fortement un système sur ce
> genre de paquets et sur ce point je pense moi aussi que c’est une
> mauvaise idée.

On est d’accord. Même pour LilyPond, encore une fois, si les
distributions font correctement leur boulot le paquet natif devrait
être largement suffisant pour beaucoup d’utilisateurs/trices.
Autrefois Fedora (et la plupart des distributions RPM), mais aussi
Arch et même Slackware, ont toujours été irréprochables ; il reste à
voir si ça va reprendre à l’heure actuelle.

> Bon, cela dit, il y a un autre problème : Flatpak et Snappy répondent à
> des questions d’utilisateurs, mais la création de ces paquets est à la
> discrétion des développeurs, qui eux n’arrive pas à en voir l’intérêt…

Si, précisément ! GUB était justement conçu pour répondre à ce besoin,
longtemps avant FlatPak, Snappy et même AutoPackage. Certes, sans
gestion des mises à jour, mais en revanche avec un atout de poids, qui
est la compilation multi-plateforme. (D’ailleurs il y a même eu une
époque où des installeurs Win/Mac/Nux/BSD pour OpenOffice et Inkscape
étaient générés par GUB.)

Aujourd’hui, GUB accuse son âge (et c’est même toute l’infrastructure
de compilation de LilyPond qu’il faudrait revoir entièrement, mais on
parle là d’un boulot titanesque), mais au moins on est arrivés à le
refaire marcher après trois ans de panne ; il n’y a absolument pas les
ressources pour arriver à lui faire cracher des paquets flat/snap/dock
(et je ne sais même pas si ce serait possible sans nuire au support
multi-plateforme) donc, if it ain’t broken,…

V.