Jonas Hahnfeld <hah...@hahnjo.de> writes: > Am Sonntag, den 08.03.2020, 11:54 +0100 schrieb David Kastrup: >> Han-Wen Nienhuys < >> hanw...@gmail.com >> > 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. >> 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. 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. -- David Kastrup
