Hi, > I think that we should revert this change for the time being, though, > because if it was working in this way for about a decade and the > programs using FTGL worked "fine" despite having some bug there,
Sorry, they did *NOT* all work fine, see my bug report. And if we apply my patch from 742469 instead, that might break programs in other ways (and will require yet another breaking change in the future, when we apply sammy's patch properly). > there's no need to change this now and break applications with only a > few weeks to fix this in 15+ other packages before the freeze. For me, there was very much a need to change. This was one of the reasons I started working on ftgl at all if you remember. Without either fix (sammy's or mine), ftgl is useless to me, so I'm not gonna do this in my repo. > Otherwise we have to get the fix in several of this packages, which is > way more difficult, specially if not well maintained in Debian, > upstream or both. As I said, it's a messy situation. A bug that was actually fixed in 2009, not applied downstream, rediscovered by me in 2014, and accidentally pulled downstream by syncing from the repo you pointed me do early this year (which I had (naively?) assumed to be mostly in sync with your version). I'm used to bugs in Debian getting ignored for years and the wontfixed (or silenly buried), but that mess seems to be special even in comparison. So what can we actually do now? - If you view it as an ABI breaking change, I can bump the version to 3.0.0, just let me know. (This would mean that programs using the library would need to be rechecked anyway, right? So if we document this prominently, they'll know what to look for, both in source code and in program behaviour.) - If you insist on a version without either of those bugfixes, do this in your code, but then I'm out, sorry. For me this will mean at least 2 more years working with an out-of-distro version (and I fear it would get neglected again, so maybe more like 10 more years or forever), so I'd have no reason to care about the distro version. - Otherwise just let the other packages find and fix the resulting bugs, like the saying goes "better ask for forgiveness than for permission". - A slightly more complex solution would be a flag to select the behaviour. Of course, it would need to be a runtime flag. It may default to the old behaviour, but that should be deprecated (and print a strong depreciation message -- unfortunately that would have to be at runtime too AFAICS, or is there a way to warn at compile time when a program, say, does *not* reference a particular function?). Cheers, Frank
