Re: git: 25e6f68a6661 - main - textproc/libxml2: Update to 2.11.6

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.