On Wed, 2023-05-10 at 19:01 -0700, Sean Whitton wrote: > On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote: > > Cool, then let's ask tech-ctte. > > > > Dear ctte, please consider overruling the dpkg maintainer to > > include > > the patch from #994388[1]. > > > > Thanks, > > Ansgar > > > > [1]: https://bugs.debian.org/994388#397 > > This would require a new, maintainer-overruling vote. > Our existing decisions do not apply, so far as I can tell.
Yes, I agree. > I have written a separate message to the bug and to debian-dpkg with > a proposal to avoid having to have such a vote. That seems to be about an implementation detail on how to apply the patch. I don't think that is the core of the issue? The core issue as I see it is as follows: - Debian has decided to support only merged-/usr, including possibly moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 as the interpreter in binaries. - This change breaks on non-merged-/usr systems, including derivatives that do not revert *all* relevant changes. (Do you know one that does this or plans to do so?) - dpkg recommends derivative users to move to non-merged-/usr. I think this contradiction is not good and the core conflict. For me a distribution should have some coherence. It is not just a distribution of unrelated parts (like linux, libc, dpkg, dash, ...), but also integrates them to work together. And this also means not one package telling users to do X which breaks other packages. Or (if other packages would do similar things as dpkg) one package asking users to do X and the other asking users to do the opposite of X. Just imagine dpkg asking users to move to split-/usr and then another package starting to warn users to move back to merged- /usr. Would that be a good state? I think not which is why this bug exists. Do you think this summary of the issue is right? Is there some consensus about how this issue should be solved or do we need a longer discussion to explore the solution space? Ansgar
