lilypond-user-fr
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problème de version et de cymbales


From: Yoann LE BARS
Subject: Re: Problème de version et de cymbales
Date: Tue, 5 May 2020 17:39:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

        Salut à tous !

Le 05/05/2020 à 16:41, Valentin Villenave a écrit :
> Je pense que dans le cas de LilyPond, cela faisait simplement
> double-emploi avec les installeurs gub.

        Sauf qu’en l’espèce GUB est spécifique à un petit nombre d’applications.

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

        Il n’empêche : on voit régulièrement passer sur les listes consacrées à
LaTeX cet argument : TeXLive, ça roule tout seul.

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

        C’est-à-dire que la version de Lilypond d’Ubuntu est la version de
Debian et Lilypond n’est pas dans les /backports/ Debian parce qu’il n’y
a pas suffisamment de monde pour lui faire passer les tests de qualités
nécessaires pour intégrer les /backports/. Pour ma part, je n’ai pas été
capable de faire passer ma correction d’un bogue bloquant d’Ardour dans
les /backports/, donc clairement seul je ne ferais pas passer Lilypond
dans les /backports/.

        Ubuntu se focalise sur un certain nombre de paquets et Lilypond n’en
fait pas partie. Sous Debian, cela fonctionne sur la base du volontariat
et il n’y a pas assez de volontaires pour Lilypond. Après, je ne sais
pas comment évaluer le rapport de causalité avec le fait que peu de
développeurs de Lilypond utilisent Debian.

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

        Évidemment, les développeurs considèrent que leur application est très
importante. Cependant, une distribution ce sont des milliers
d’applications et il n’est pas si évident d’assurer une bonne
consistance de la distribution en mettant à jour les logiciels aussi
régulièrement que tous les dix jours, sauf avec des choix comme ceux
d’Archlinux qui demandent aux utilisateurs un niveau de connaissances
techniques assez important.

        Du coup, pour les cas où les développeurs considèrent qu’il est
important que les utilisateurs puissent accéder à une nouvelle version,
mais où ce sera compliqué pour les mainteneurs de distributions de la
mettre à disposition, Flatpack offre une solution.

> 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,…

        En tout cas, il n’est pas pertinent d’utiliser plusieurs formats de ce
type de paquets, puisque le propos est justement de ne faire qu’un seul
paquet pour toutes les distributions. Ce qui répond à la question du
multi-plateforme : ces formats sont multi-plateforme. Par exemple, même
si Canonical développe Snappy, il est parfaitement possible de faire
tourner un paquet Flatpack sur Ubuntu.

        Par ailleurs, pour avoir testé ces systèmes, du point de vue de
l’utilisateur c’est vraiment très simple.

        À bientôt.

-- 
Yoann LE BARS
http://le-bars.net/yoann/
Diaspora* : address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]