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

[Jonas Hahnfeld]

Am Samstag, den 14.03.2020, 11:36 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> address@hidden
> > writes:
> 
> > Am Samstag, den 14.03.2020, 11:17 +0100 schrieb David Kastrup:
> > > Jonas Hahnfeld <
> > > address@hidden
> > > 
> > > > writes:
> > > > Am Samstag, den 14.03.2020, 10:50 +0100 schrieb David Kastrup:
> > > > > Jonas Hahnfeld <
> > > > > address@hidden
> > > > > 
> > > > > 
> > > > > > writes:
> > > > > > Am Freitag, den 13.03.2020, 23:09 -0600 schrieb Anthony Fok:
> > > > > > > On Fri, Mar 13, 2020 at 2:02 AM Jonas Hahnfeld <
> > > > > > > address@hidden
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > wrote:
> > > > > > > > I'm still not convinced that we need compatibility code, but 
> > > > > > > > I'm happy
> > > > > > > > with anything that gets us to a release and is not technically 
> > > > > > > > wrong.
> > > > > > > 
> > > > > > > By the way, from a Debian package maintainer point of view, 
> > > > > > > breaking
> > > > > > > backward compatibility is OK as long as it is documented, so if
> > > > > > > breaking backward compatibility makes the code cleaner, more 
> > > > > > > correct,
> > > > > > > and/or easier to maintain for the future, I'd say "please break
> > > > > > > compatibility"!
> > > > > > 
> > > > > > I definitely think that's the case here.
> > > > > 
> > > > > Backward compatibility will always get retired eventually.  For the
> > > > > current decision the main target is not really distributions since 
> > > > > those
> > > > > tend not to package unstable versions anyway.
> > > > 
> > > > Exactly my argument in the past. So who is the "main target" in your
> > > > opinion? I mostly remember the term "system integrators".
> > > 
> > > Is there a reason we should not be catering well to either?
> > 
> > I still don't understand who your "main target" is. Wrt "system
> > integrators" Anthony wrote that breaking compatibility is fine (for
> > major versions) as long as there is documentation.
> 
> Our current state is breaking things silently and without documentation
> that were required to get things working before.
> 
> The consequences are different for different people, depending on their
> contact with LilyPond and their skill sets in dealing with such
> problems.  This is a problem with keeping our current processes
> depending on volunteers operating as expected.  That also maps to people
> expected to compile their own versions.  Distributions like those for
> Debian, FreeBSD and more recently also MacOSX work independently from
> our core developer team and should be able to get results they expect.
> 
> What is the problem you are trying to address with your "main target"
> question?

I'm trying to find a way forward so we can get 2.21.0 released. I've
thrown out a few ideas which you've all said we should not do. So what
do you want?! This discussion is dead without knowing that.

Let me rephrase what I think we should do:
1) Keep using pkg-config to find Guile.
2) Add an error if we detect that a configuration uses the old
GUILE_CONFIG.
3) Add documentation about how to make pkg-config find the right
version of Guile, saying that 1.8 is still the one you should target
for now.

Jonas

signature.asc
Description: This is a digitally signed message part