Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

> Am Samstag, den 07.03.2020, 11:19 +0100 schrieb David Kastrup:
>> 
>> We are not talking about "keep everything compatible".  We are talking
>> about making changes in a manner where they don't trip people up.  They
>> way to deprecate a way of doing things is not to _start_ by pretending
>> it never existed and silently ignore attempts to use it.  At the same
>> time, by the way, not adapting any bit of documentation.
>
> Acknowledged.
>
>> For better or worse, deprecation takes work.  That's why we have, for
>> example, convert-ly.  That's a user-level feature, but basically
>> asserting that people able to compile LilyPond have to be able to deal
>> with anything we throw at them without comment is not going to go down
>> well with regard of keeping LilyPond supported by, say, major GNU/Linux
>> distributions.
>
> Do expect "major GNU/Linux distributions" to package unstable
> releases? I hope we don't force them by taking another 6 years for
> 2.22

You make a good argument for keeping the deprecation warnings and code
in for at least 2.22 so that major GNU/Linux distributions will be able
to follow along.

The usual deprecation path for stuff like this is:

1 stable release with continued support but warning containing all
    necessary migration information -> 2.22
    
1 stable release with discontinued support but error containing all
    necessary migration information -> 2.24

1 stable release with active support removed but transition explained in
documentation -> 2.26

no mention anymore in code base -> 2.28

However, if there is no pressing reason to remove stuff (like when it
actively stops working or nobody knows for sure), the benefits of
complete removal may not outweigh the drawbacks.

> In the long run I'd expect "major GNU/Linux distributions" to ditch
> Guile 1.8,

Debian/Ubuntu already did.  LilyPond comes with its private copy of
Guile-1.8 and we don't want to make it even harder for the people
providing LilyPond to make this owrk.

> and I hope we can do the same in LilyPond not so far in the
> future. That will be so fundamentally different that not being able to
> use the GUILE_CONFIG environment variable

GUILE_CONFIG works fine with Guile-3.0.

> is the least of your changes you have to make for your build
> configuration. Btw upstream deprecated guile-config, so pkg-config is
> really the way to go.

I think you need to distinguish "deprecate" from "stop to make work" and
"pretend it never was a thing".

I have no beef with deprecating it.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".