On April 8, 2022 6:31:27 AM PDT, Wookey <woo...@wookware.org> wrote: >If they want to prove that no patches for the current approach will >ever be accepted, that can only be done by engaging further. Yes it >will be hard work, but if it's not done we are just stuck.
It sounds like at least one patch has already been rejected, not with comments about the patch needing work (which it absolutely does), but AIUI with "usrmerge is broken by design". That seems like sufficient proof that the problem is not a lack of engagement or patches. I don't think it's reasonable to expect further one-sided engagement by way of further "proof" of futility. That's leaving aside the (likely also accurate) expectation based on reported experiences with multiarch that any patch will go through extreme amounts of rework and iteration in that hostile environment, even *if* there were enough trust left to expect good faith. I would love to see some engagement from the dpkg side, beyond reverting NMUs and subverting project decisions. Literally a single sentence would largely solve this: "as much as I disagree with this decision, I will stop shipping or recommending dpkg-fsys-usrunmess, and I will merge a reasonable patch to support usrmerge via directory symlinks in dpkg". In the absence of such engagement, it would help if the TC provided the equivalent of both halves of that statement. But in either case, I think it's reasonable to not expect people to enthusiastically participate in a hostile and gruelling development environment in dpkg in the wake of a TC override (whether the one mentioned here or the one that has already taken place).
