Werner LEMBERG <w...@gnu.org> writes: >> Unfortunately I ran into this very issue, changing from Debian >> stable (in the Linux Mint Debian Edition incarnation) to vanilla >> Debian testing. I did this because the PyQt5 packages in stable are >> too old to run current Frescobaldi from its Git repository. Now >> that I managed to get Frescobaldi running again I can't build >> LilyPond anymore because in Debian testing I don't have guile 1.8 >> anymore :-( >> >> For working *with* LilyPond it's not much of an issue to use the >> releases, but I can't work *on* LilyPond right now ... > > Mhmm, compiling and installing guile 1.8 is not rocket science... > Have you tried that already? > > Maybe we have to bite the bullet and distribute guile 1.8 together > with lilypond. I know that this is a step into the wrong direction > since it doesn't force the guile maintainers to improve guile 2.x so > that lilypond can use it...
The Guile maintainers are not interested in improving Guile 2.x so that LilyPond can use it. I'm no longer involved in LilyPond management, and others aren't yet banned from posting messages on Guile-devel, so ignoring them will take more than semi-annual lip service in private mail to RMS without any followup actions. I think it would be reasonable to figure out how to keep the Guile developer lists regularly informed of current problems, of the comparative performance issues, and of the necessity to revert to an older Guile version (possibly creating a fork in order to get a few more problems fixed) because Guile-2.x is a) developing in a direction making it less rather than more suited as an extension language b) not bothering at all about keeping their invested users on-board Now obviously I am not all too well-suited as a role model for communicating with Guile upstream. I'm just not the kind of man Stephen Turnbull is (who has more or less single-handedly deflated the animosity towards GNU in XEmacs, while having had more than enough personal setbacks to keep it going. And RMS has not really been the greatest help in that endeavor). But either way, I don't see that the project can do without communicating with Guile, and better than I managed doing. Even if we end up forking Guile 1, we want to do so in a manner where incremental improvements of Guile developers remain feasible/possible. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
