Re: git: 25e6f68a6661 - main - textproc/libxml2: Update to 2.11.6
Date: Sat, 13 Jan 2024 20:20:02 UTC
On 2024-01-13T20:27:45.000+01:00, Charlie Li <vishwin@freebsd.org> wrote: > Daniel Engberg wrote: >> On 2024-01-13T18:46:34.000+01:00, Charlie Li >> <vishwin@freebsd.org> wrote: >> >> The Build Instructions section of the README specifically states >> >> "Autotools (for POSIX systems like Linux, BSD, macOS)", even in >> the >> >> latest trunk. CMake was originally added mainly for Windows >> support. >> >> Their CMake support on platforms like ours still has an >> outstanding bug >> >> pertaining to dependency resolution, which at least I consider a >> >> showstopper. While upstream have been accepting and responsive to >> any >> >> and all improvements to their CMake support, that is irrelevant >> until >> >> they explicitly bless it as an equal to autotools. (Not to say >> >> autotools >> >> is perfect either, far from it) >> >> Personally, between the two choices here, I prefer CMake. But >> personal >> >> preferences are irrelevant wrt liability and support issues. >> >> Hi, >> >> That's a bit contractionary? We upstream patches, community and >> others >> >> also do and yet there's a "support issue" despite autotools is >> "far from >> >> it" (perfect)? Why not embrace instead of obstructing? Please >> keep in >> >> mind ports is a joint / community effort which is why we have >> groups, >> >> guidelines etc and for custom trees there's overlay support for >> who want >> >> or need to diverge. > > Not contradictory at all. autotools has and remains the default and > thus > > the most supported option for our case. If there is any perceived > > obstruction, it is on upstream declaring that another option is > equally > > viable and supported for our case, in a *release*. > > Community effort goes multiple ways, but the buck still stops with > both > > us and whatever upstream we port/deal with. Users in particular > could be > > reporting bugs and other issues here or upstream. We may not have > > upstream's full picture of warts and considerations; they will > certainly > > not have our (or any other operating system distribution's) full > > picture. Especially with something reported upstream that is > specific to > > our implementation, if it is because the port/package from main uses > a > > method different than that prescribed for us, it becomes our > problem! > > This is the liability. > > You can repeat the word or meaning of "collaboration" until blue in > the > > face, but the reality in the world of spare time/effort is limited. > Yes, > > anyone can use the other method in overlays and whatnot, but the > main > > ports tree needs to be kept production-ready as much as possible, > and > > part of that means respecting upstream's wishes as much as > practicable > > so that we as a community (especially including users) stay on good > > terms with upstream. We can upstream stuff that they accept to our > > hearts' content, but upstream still needs to explicitly acknowledge > them > > as production-ready before we use them in our main tree. Using a > > different method than what upstream declared for us to use is not > > exactly respecting their wishes. > > -- > > Charlie Li > > ...nope, still don't have an exit line. Hi, It's a collaboration and seemingly multiple people seem to agree both within and outside the project on that given the engagement, you seem to disagree on that which is a bit concerning. Everything is a liability like that including even updating and everything is best effort. But again, if you or others want to start to upstream Autotools fixes etc by all means go ahead but has yet to occur. If we can work with upstream and reduce the amount of local patches, hacks and have clean Makefiles that's a win for everyone irregardless of build system. Best regards, Daniel