Date: Fri, 01 Apr 2022 08:34:57 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262853 --- Comment #17 from Daniel Engberg <diizzy@FreeBSD.org> --- (In reply to Tijl Coosemans from comment #16) Agreed, it's always tricky and there are a few issues to consider overall. While it might be a combination of interest, time and funds (its been mentioned that the project pretty much recieves no funding) or something else upstream struggles with Autotools and very few induviduals in general wants to touch it. As a consequence of this we as well as other distros do various hacks to work around these issues using packaging frameworks without upstreaming because no one wants to touch it more or less and simply because they're not upstreamable. That leads us down the road of the maintenance, in that regard I think we can all agree upon that any form of patching and/or hacking by hand indirectly discourages people to work on X. Simply because it requires additional investment trying to figure what XYZ does and what it tries to fix/fixes. In that regard we do have people, there is general interest in fixing issues and upstream is willing to accept patches (https://gitlab.gnome.org/GNOME/libxml2/-/issues/360#note_1418502). If I were to speculate about upstreams current standpoint I'd guess that they're aware that libxml2 is used on various less common platforms which CMake (in this case) doesn't support and/or dropped support for a long time ago and simply don't want to take that discussion. Since several have contributed and without any vocal objections I'd assume that they're in agreement rather than disagreement. I fully agree that fallouts never are favourable and should be avoided if possible. That being said, I also think that it may sometimes be necessary to move forward within reasonable tradeoffs. Regarding dependencies it's always hard to do a good assessment simply because there's no way of telling. I do however think that while we do see projects migrating from Autotools to mainly CMake and Meson it's fair to say that most dependencies are "fortunately" stuck with Autotools due to legacy compatibility and/or to simply avoid circular dependency. In case of a switch I think we're more likely to see a switch to Meson rather than CMake to avoid circular dependency and due to the fact that CMake and/or Meson are a lot less painful to use on Windows platforms than Autotools which many dependencies also targets. Best regards, Daniel -- You are receiving this mail because: You are the assignee for the bug.