Hi, On 5/11/23 10:59, Sean Whitton wrote:
Dear ctte, please consider overruling the dpkg maintainer to include the patch from #994388[1].
Currently dpkg contains code to emit the merged-/usr warning, that's dead code on Debian, but which becomes active when packages from the Debian archive are copied unmodified into derivatives.
The way I see it (but I'm not a dpkg maintainer), the current implementation is correct, as dpkg does not support aliased directories, but Debian has decided to use it in such an environment nonetheless. The tech-ctte decision not to roll back usrmerge accepts responsibility for this decision, so silencing the warning on Debian is correct, but no one has accepted that responsibility for derived distributions.
Any derived distribution can easily go on record and request inclusion in the list of distributions where this warning is suppressed, by typing the phrase "Yes, I understand that this is a bad idea." into an email client.
dpkg has an upstream existence that's independent of Debian, and it's perfectly legitimate for that version of dpkg to emit the warning. The problem here might be caused by how the Debian archive is implicitly being used to distribute upstream dpkg.
I'm skeptical about splitting development and packaging, though, especially in this context, because we'd need to clarify how far we'd want upstream dpkg and Debian dpkg to deviate.
Basically, non-native dpkg has two scenarios: either it is maintained by the same people as now, which causes them extra work for no clear benefit, or we find maintainers willing to deal with complex bug reports that upstream is fully entitled to reject because Debian brought this onto themselves by deciding that one upstream project's "unsupported configuration" needs to be avoided by moving to another upstream project's "unsupported configuration."
Those same people who would volunteer to maintain such a package could spend their energy finding a solution that can be merged into "upstream" dpkg, that would be more productive.
Simon