LilyPond est un générateur de partitions musicales à partir de fichiers textes. C’est une sorte d’équivalent de LaTeX pour la musique.
La qualité des partitions générées est très haute, pour preuve Daniel Spreadbury dans son blog concernant le prochain éditeur de partition de Steinberg qui utilise LilyPond comme référence (sous l’appellation “Product C”).
Le soft freeze de Debian 9.0 Stretch vient de passer, et LilyPond n’a pas pu être intégré à la distribution testing
.
Cela signifie que ce paquet ne sera pas présent dans la prochaine version de Debian.
Source : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005#263
L’affaire remonte à plus de deux ans quand Debian a décidé d’enlever le paquet guile-1.8
pour le remplacer par guile-2.0
.
GUILE est une dépendance de LilyPond et il semble que le portage de cette bibliothèque n’est pas simple à cause du ramasse-miette de GUILE 2.0 qui n’est pas fiable d’après les développeurs de LilyPond.
Pourtant l’annonce du changement de version remonte à deux ans en arrière, le 26 avril 2014.
Aucune version n’ayant pu être livré à temps, LilyPond a été automatiquement enlevé de la distribution testing
le 24 juin dernier et n’est pas revenu depuis.
Dommage…
Se pose ainsi la question du modèle choisi par Debian.
A cause de l’engagement pour un système le plus stable possible, on se retrouve avec des logiciels soit obsolètes, soit absents.
Je pensais avoir trouvé un bon compromis en utilisant la version testing
de Debian, mais l’absence de Lilypond depuis plus de 6 mois m’interroge.
Qu’en pensez-vous ?
# Logiciel libre
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Vient alors la question du modèle du logiciel libre! Celle-ci implique que tu n'es pas forcé d'attendre d'avoir un logiciel dans le système de paquet de ta distrib pour l'installer toi-même.
Alors je me rends bien compte que c'est chiant. Même en tant que développeur, c'est jamais une partie de plaisir de compiler des logiciels. Je préférerais de loin les avoir tout faits, prêts à utiliser.
Mais bon, au moins c'est possible! Et il m'arrive ainsi régulièrement de m'installer des outils logiciels qui ne sont pas dispos dans ma distrib. :-D
La seconde réponse: peut-être pourrais-tu discuter avec les dévs de Lilypond et leur proposer de proposer un paquet indépendant? Je pense notamment à Flatpak. Quiconque pourra alors installer Lilypond indépendamment et les dépendances principales seront embarquées. Plus de problème de ce côté là. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Logiciel libre
Posté par arnaudus . Évalué à 10.
Je trouve que ce qui se pose comme question, c'est plus le modèle choisi par Lilipond. Une dépendance vers une ancienne version d'une bibliothèque tierce qu'on n'arrive pas à transformer vers une dépendance sur une version à jour, c'est problématique. Ça veut forcément dire qu'un jour ou l'autre, il y aura un pépin (ancienne version de guile plus maintenue).
Il y a plein de solutions pourtant : intégrer guile-1.8 ou une sous-partie à Lilipond, intervenir pour fixer les bugs de guile-2.0, ou carrément changer de dépendance si on pense qu'elle n'est pas fiable.
[^] # Re: Logiciel libre
Posté par JoeltheLion (site web personnel) . Évalué à 8.
Plus facile à dire qu'à faire. Le moins qu'on puisse dire, c'est que quand l'upstream d'une dépendance que tu utilises beaucoup commence à faire des choses qui ne t'arrangent pas, tu es dans une grosse galère…
[^] # Re: Logiciel libre
Posté par lasher . Évalué à 2.
Au boulot j'ai une RHEL 7.2, et guile 1.8 ET 2.0 sont installés. Je ne comprends pas que Debian ne permette pas d'installer les deux bibliothèques couramment.
[^] # Re: Logiciel libre
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
C'était le cas jusqu'à maintenant. Ils ont prévenus Lilypond que c'étaient les derniers à utiliser Guile 1.8 lors de la release précédente et avaient déjà conservé ce paquet pas maintenu rien que pour eux. Entretemps, le problème n'est toujours pas réglé.
Si la migration n'est vraiment pas possible, il aurait fallu que Lilypond (ou quelqu'un d'autre) forke Guile 1.8 et prenne en charge la maintenance. Personne chez Debian n'ayant envie de le faire.
[^] # Re: Logiciel libre
Posté par mzf (site web personnel) . Évalué à 2.
C'est vrai que lorsque MuseScore 2.0 est sorti, c'était bien pratique d'utiliser leur AppImage en attendant le retro-portage.
[^] # Re: Logiciel libre
Posté par Parleur . Évalué à 3.
Plutôt que de compiler, dans le cas précis de Debian et Lilypond, ya quand-même plus simple : Lilypond est dans unstable. Un peu d'apt-pinning, et c'est réglé.
[^] # Re: Logiciel libre
Posté par dromadaire35 . Évalué à 2.
Sauf que le paquet dans unstable dépend de guile-1.8, qui n'est présent ni dans testing, ni dans unstable, ni dans experimental. Du coup, compiler c'est probablement plus simple.
[^] # Re: Logiciel libre
Posté par Sufflope (site web personnel) . Évalué à 2.
Bon j'ai pas trop cherché si ça marche avec les applis graphiques (ça doit pouvoir se faire) mais lancer un soft dans une vieille version sur un OS dans une vieille version c'est là où docker excelle (plus que dans la prod' en tout cas :troll: )
[^] # Re: Logiciel libre
Posté par Albert_ . Évalué à 3. Dernière modification le 11 janvier 2017 à 14:37.
Oui mais docker et les applis graphiques c'est un peu la croix et la baniere tout de meme. Enfin d'apres mes essais d'il y a quelques mois.
edit: lillypond n'est pas graphique…
[^] # Re: Logiciel libre
Posté par Parleur . Évalué à 1.
Ha oui. Au temps pour moi. Et en mixant avec les dépôts de Jessie ?
# Viens du bon côté de la force...
Posté par karchnu . Évalué à 10.
OpenBSD a un paquet lilypond, viens vers nous, on mort pas et on est déjà 5 !
[^] # Re: Viens du bon côté de la force...
Posté par totof2000 . Évalué à 10.
On dit "on bronsonize pas" (cela dit je me demande ce que veut dire ta tournure de phrase).
[^] # Re: Viens du bon côté de la force...
Posté par karchnu . Évalué à 2.
Haha, j'ai écrit ça un peu vite-fait, pas fait gaffe à cette énorme érreure.
[^] # Re: Viens du bon côté de la force...
Posté par mzf (site web personnel) . Évalué à 2.
Ha ha, je ne suis pas encore assez barbu pour OpenBSD ;-)
http://rebrn.com/re/your-average-openbsd-user-1906639/
[^] # Re: Viens du bon côté de la force...
Posté par karchnu . Évalué à 10.
En vrai, c'est assez simple. Si tu t'intéresses un peu au fonctionnement, tu te rends vite compte que c'est même souvent plus simple que sous Linux, sur plusieurs points.
Après je veux pas non plus te forcer la main, c'est juste que c'est mieux pour toi, ton ordinateur, les gens autour de toi, ça te rend souriant, en bonne santé, ça t'aide à arrêter de fumer, à retrouver l'amour, à gagner confiance en toi et ça te rend plus intelligent. Mais c'est toi qui choisi.
[^] # Re: Viens du bon côté de la force...
Posté par totof2000 . Évalué à 10.
A priori, le leader du projet n'utilise pas assez son propre OS.
[^] # Re: Viens du bon côté de la force...
Posté par David Marec . Évalué à 3.
Chez FreeBSD aussi, que vous soyez en
CURRENT
,RELEASE
ouSTABLE
!Ceci dit, il faut admettre que ce soft dépend de
lang/guile
(la version 1.8) et que ce dernier est en conflit aveclang/guile2
(la version 2.0.11).On ne peut donc installer les deux, sauf à utiliser une
jail
, bien sûr.s/t/d ?
5 à vous partager la cagnotte ?
cool !
[^] # Re: Viens du bon côté de la force...
Posté par chimay . Évalué à 1.
yep, ce qui ne les empêche pas de proposer firefox 50 et des poussières,
par exemple.
# stable + machine virtuelle
Posté par koopa . Évalué à 3.
Le problème avec
testing
c'est que tu ne peux pas facilement revenir en arrière en cas de problème et tu es obligé d'attendre qu'un nouveau correctif soit publié. Donc pour ma part, je reste surstable
et j'utilise des machines virtuelles pour les logiciels qui me manquent.[^] # Re: stable + machine virtuelle
Posté par mzf (site web personnel) . Évalué à 3.
Tes machines virtuelles font tourner Debian
testing
? ou une autre distribution qui contient les logiciels qui te manquent ?# Pas obsolète
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10. Dernière modification le 06 janvier 2017 à 12:53.
Ben non, ça n'a rien à voir, au contraire. À cause de la lenteur des développeurs de Lilypond pour passer à la version actuelle de Guile, ce logiciel ne peut plus figurer dans la testing qui est trop à jour pour permettre de l'utiliser avec sa dépendance obsolète.
Si tu veux utiliser Lilypond, ce n'est pas un système moins stable et plus récent qu'il te faut, au contraire, c'est un système plus antique de figé. Autrement dit, la Debian précédente.
[^] # Re: Pas obsolète
Posté par JoeltheLion (site web personnel) . Évalué à 7.
C'est quand même un peu facile de leur faire porter le chapeau. S'ils disent vrai et que le ramasse-miettes de Guile 2.0 n'est pas fiable, je comprends qu'il n'ait aucun empressement à adopter cette "mise à jour".
Et puis une mise à jour de ce style peut parfois être un gros boulot, sans intérêt majeur pour les utilisateurs finaux. Que dirais tu si Debian décidait de remplacer Python par Python3 et virait tous les logiciels qui n'ont pas suivi ? Ou Perl5 par Perl6 ?
[^] # Re: Pas obsolète
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
À ma connaissance, Python 2 et Perl 5 ne sont pas caduques et sans aucune mise à jour depuis 7 ans.
[^] # Re: Pas obsolète
Posté par JoeltheLion (site web personnel) . Évalué à 7.
Je comprends ton point de vue, mais on peut difficilement reprocher aux développeurs de LillyPond le fait que Guile 1.8 soit abandonné. Et s'il remplit leur besoins, je peux comprendre leur manque de motivation à migrer.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pas obsolète
Posté par G.bleu (site web personnel) . Évalué à 4. Dernière modification le 06 janvier 2017 à 18:33.
C'est sûr que ça fait un sacré argument pour passer à lua: tu balances ses 800ko de .c/h en vrac dans tes sources et basta, plus personne ne viendra t'emmerder après ça ;-)
# NiX
Posté par Anthony Jaguenaud . Évalué à 10.
Salut,
Quand j’ai un logiciel qui n’est pas présent, je l’installe avec nix-env le gestionnaire de paquets de NixOs le paquet lilypond est présent en 2.18.2
[^] # Re: NiX
Posté par chimay . Évalué à 1.
Il faudra vraiment que je me décide à l’essayer dans virtualbox.
Au niveau des paquets disponibles, est-ce assez fourni ou faut-il passer
régulièrement par des dépôts tiers ?
# Cohabitation de versions
Posté par gouttegd . Évalué à 10.
Qu’il y a une solution simple : Guile 1.8 et Guile 2.0 peuvent parfaitement cohabiter sur le même système.
Je le sais, parce que j’ai été confronté au même problème lorsque Slackware est passé de Guile 1.8 à Guile 2.0 : tout d’un coup, je ne pouvais plus compiler Lilypond. Sauf qu’en fait il n’y a aucun problème : j’ai juste installé Guile-1.8 à côté, et tout le monde est content.
Pourquoi cette solution n’est pas acceptable pour Debian ?
[^] # Re: Cohabitation de versions
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Deux raisons. La première, qui est le plus importante : parce que personne ne s'est porté volontaire pour maintenir un paquet guile-1.8 pour les deux années à venir. Et la seconde, qui est sans doute la cause de la première : parce que c'est obsolète depuis longtemps et plus du tout maintenu en amont, ce qui signifie que tout le travail de maintenance, y compris l'adaptation, voire la rédaction des corrections de sécurité, incomberait au mainteneur de ce paquet.
Maintenant, si tu es prêt à te charger de l'empaquetage, et à faire en sorte de corriger d'une façon ou d'une autre les failles de Guile 1.8 alors que plus aucune version n'en a été publiée depuis décembre 2010, tu peux toujours te porter volontaire, mais j'ai peur qu'il ne soit un peu tard pour cela maintenant.
[^] # Re: Cohabitation de versions
Posté par mzf (site web personnel) . Évalué à 10.
Apparemment Guile 1.8 a été gardé dans Debian Jessie seulement pour LilyPond. D'après leurs échanges on peut en déduire que les mainteneurs de Debian espéraient que 2 ans seraient largement nécessaires pour la migration vers Guile 2.0.
Source :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005#77
[^] # Re: Cohabitation de versions
Posté par Cyril Brulebois (site web personnel) . Évalué à 3.
Merci de m'avoir évité la séance archéologie, c'est ce que j'avais en tête en voyant ce journal. ;)
Debian Consultant @ DEBAMAX
# Troll
Posté par MTux . Évalué à 10.
Pour une fois que Debian est trop récent pour un logiciel…
# du récent avec lilypond ? :)
Posté par chimay . Évalué à 4.
Voyons voir :
Les deux versions de la bibliothèque sont installées.
Et
lilypond
?C’est là que tu te dis que tu es bien content d’être passé sur l’Arch.
# Backport
Posté par Vincent Bernat (site web personnel) . Évalué à 5.
Ce n'est pas dramatique non plus. Si LilyPond sort une version qui se compile avec Guile 2 dans quelques mois, il sera toujours possible de la backporter pour Stretch. Il suffit de continuer à utiliser le LilyPond de Jessie en attendant.
# Manque de main d'œuvre
Posté par gasche . Évalué à 8. Dernière modification le 09 janvier 2017 à 23:57.
Pour moi le problème c'est surtout un manque de main d'œuvre, à la fois côté Guile et Lilypond. Ce sont des projets qui sont portés par un groupe de volontaires, et quand un problème se pose qui est trop technique ou spécialisé pour la plupart des gens, on se retrouve avec au mieux une personne de chaque côté qui comprend le soucis, et ça progresse très lentement — c'est normal.
La solution n'est pas spécialement de changer le "modèle Debian", c'est plutôt que les gens qui trouvent ces logiciels importants essaient de se retrousser les manches pour aider à continuer à les faire vivre. (Ça ne veut pas forcément dire aller résoudre ce problème ultra-spécifique là : si on aide à relire des patches ou corriger des bugs, on peut libérer du temps des développeurs existants pour regarder les parties les plus techniques.)
L'important ici n'est pas spécialement de penser, mais plutôt de faire.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.