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

[Jonas Hahnfeld]

Am Sonntag, den 08.03.2020, 12:34 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> address@hidden
> > writes:
> 
> > Am Sonntag, den 08.03.2020, 11:54 +0100 schrieb David Kastrup:
> > > Han-Wen Nienhuys <
> > > address@hidden
> > > 
> > > > writes:
> > > > > What about "an error would be a nuisance when trying to have a common
> > > > > configuration for both 2.20 and 2.21" was unclear?
> > 
> > There will never be a shared configuration for both 2.20 and 2.21:
> > Current master requires Python 3 which 2.20 not even attempts to be
> > compatible with.
> 
> Many systems install both Python2 and Python3 and the respective
> configure scripts are perfectly fine finding and using the required
> version.  I wasn't trying to imply that we can share the _results_ of
> running configure, but a common starting position, given the autoprobing
> nature of autoconf, is a lot more realistic.

My point is that setting the PYTHON variable is equally broken.

> > > This would concern things like running Patchy, and also things like
> > > checking out pretests of stable releases for system packages.  If the
> > > spec files of the stable release fails mysteriously, most users will
> > > give up.
> > 
> > With the patch it doesn't fail "mysteriously" - there's a clear error
> > saying what the tester is supposed to do. And from my understanding
> > "unstable" releases really means that.
> 
> Prereleases aren't as unstable.
> 
> > > I cannot believe the resistance against creating a few dozen lines
> > > for making the life for users and testers of LilyPond easier and
> > > insisting on a configuration that will fail for everything except a
> > > single painstakingly "correct" use that is not documented.
> > 
> > As I wrote yesterday, the whole thing wasn't documented before.
> 
> That's not something to be proud of.  It means that things tended to
> work by heresay and recipes passed around that took some pain to figure
> out.  It's not a state to aim for.
> 
> > I politely ask to take a step back and try to understand the point of
> > view shared by Werner, Han-Wen and me.
> 
> That basically amounts to "we can figure it out, so everybody else
> should".  I don't doubt your competency, but it just isn't
> representative for everyone wanting to use/compile/support LilyPond.

No, it amounts to "it works the same as it does for other packages".

> It isn't, for example, representative for the people typically doing git
> bisection in order to find out where something went wrong.  Hard cutoff
> points in working configurations make something like bisection a lot
> more painful.

Not being able to change gradually makes development more painful.
There was discussion as to why there are so few developers - this will
be my prime reason if I'm required to add compatibility for everything.
Yes, this includes things so fundamental as Guile.

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