Re: Pango Update in new binaries

[David Kastrup]

Federico Bruni <address@hidden> writes:

> 2015-04-07 19:47 GMT+02:00 Joshua Nichols <address@hidden>:
>
>> Hello all,
>>
>> I apologize if this question has already been asked.
>>
>> Has the new version of pango been ported to the binaries on
>> mac/windows/linux? I noticed here
>> <https://code.google.com/p/lilypond/issues/detail?id=2656> that there has
>> since been bug issues with a previous version that LilyPond has been using,
>> and now there's been fixes to those bugs. I noticed its in the latest dev
>> release of LilyPond, but my question is: is it being retroactively
>> implemented in the stable release?
>>
>>
> Hi Josh
>
> Nobody replied to you.
> According to a recent discussion in this list, it seems that the new Pango
> version in GUB makes lilypond compile much faster. This would be another
> good reason to make a 2.18.3 release. Unless 2.20 is close... What
> developers think about it? (I'm cc-ing lilypond-devel).

I don't think 2.20 is that close: it would be nice to have it work with
GUILE-2.0.  There is rather slow progress on this: the main symptom of
any progress is occasional weird commits to LilyPond, a large amount of
frustration and procrastination on my side that leads to low
responsiveness and productivity of mine, and a number of bug reports of
mine eventually making it into the GUILE issue tracker.

Basically, it's a continuous stream of "oh, that doesn't seem to work
under those circumstances" or "oh, that doesn't seem to work as
intended" with suggestions for alternatives that trip up in different
ways.  And tracking and boiling the new problems down into useful test
routines one can report is not fun.

I am not sure that I'll have every problem in check by the time
GUILE 2.0.12 comes out.

However, it would appear that the 2.18 variant you are envisioning is
basically rather 2.18.3a: identical sources, different build system.

It might be possible to roll something like that if it would help
people.  It would still self-identify as 2.18.3 but the installers would
get a different file name.  No idea how much of a nuisance that would be
for our package providers.  If that trips up procedures all too much,
one might just release 2.18.4 "regularly".  But then the question arises
whether one should incorporate other fixes.

-- 
David Kastrup