[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)



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).

Ansgar


Reply to: