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

Kind regards,
Luca Boccassi

Reply via email to