On Thu, 18 May 2023 at 19:27, Ansgar <ans...@43-1.org> wrote: > > On Thu, 2023-05-18 at 12:14 -0600, Gunnar Wolf wrote: > > Ansgar dijo [Thu, May 18, 2023 at 07:55:03PM +0200]: > > > Why not? > > > > > > Do you think the implications of removing the warning are unclear? > > > > > > Do you think we need to explore alternative solutions? > > > > (I am no longer part of the Committee, answering just as another > > developer) > > > > dpkg has many bits that make it special. It has been discussed whethe > > dpkg should be a native package or it should become non-native; if it > > were non-native, having a patch that contradicts the upstream > > author's wishes would be easier (and I'm not saying that I'd be up > > for patching this warning out as it is). > > Do you think this implementation detail is relevant for what we do in > Debian? I don't care how a patch is applied and don't think that detail > has to be part of the decision. > > I also don't see any further active discussion on this aspect (unless I > missed something). > > > > If we were to force a patch silencing out this warning right now and > > for all of the Bookworm cycle, and the dpkg authors disagree with it, > > they could remove (even omit to include it) in any updates. > > So? That is the case with any ruling the ctte makes, including the non- > binding one the ctte just did under Constitution 6.1.5. > > > Upstream > > has repeatedly expressed their opposition to the way usrmerge has > > been brought forward, and the warning silenced specifically for > > Debian is already the best compromise situation we have been able to > > reach -- even though we are aware the situation is far from ideal. > > If the best solution we have been able to reach is telling users of > derivative distributions to configure their system in a way that is > expected to cause breakage, then it would be worth documenting that > this is the case and we cannot do more for derivative users. > > If the ctte believes this to be fine, then the ctte can decide to not > overrule the maintainer. > > I don't think this is a good reason to delay the decision indefinitely > unless there is some reason to believe something will change within a > reasonable period of time (which I don't see happening).
We heard so much in the past couple of weeks about how important it is for the project not to cause issues for derivatives and cross-compatibility use cases, even speculatively. This is not even speculative, it is certain to cause damage (as we experienced first hard last year), I don't see how we can ignore it after all of these discussions. Kind regards, Luca Boccassi
