Re: Which Linux distro for Lilypond

[David Kastrup]

Werner LEMBERG <address@hidden> 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