Hi Ben, Dropping leader@ and community@ from Cc as this is a technical side-track.
On Thu, Sep 12, 2024 at 12:38:24AM +0200, Ben Hutchings wrote: > On Mon, 2024-09-09 at 02:13 +0200, Ben Hutchings wrote: > [...] > > My answers below are mine alone. I have not discussed this with other > > team members and do not speak for them. > > > > On Wed, 2024-09-04 at 15:30 +0200, Stefano Rivera wrote: > > > Hello kernel maintainers, > > > > > > While potential solutions to this bug are being discussed, would you > > > please consider removing the Provides from linux-libc-dev? > > > > I am open to doing so. > [...] > > I raised this at today's team meeting and it was agreed to do this; see > <https://salsa.debian.org/kernel-team/linux/-/merge_requests/1198>. Thank you. I note that these provides (while causing problems) also solved one problem that now reappears. linux-libc-dev is marked `Multi-Arch: foreign`, but this technically is a lie. It does not provide linux-libc-dev for all architectures - not even for all linux-any architectures and never will. Whenever we add an architecture, a new niche architecture comes along. This gives rise to the need to tell apart from the package metadata whether linux-libc-dev provides headers for a given architecture. Before the change from Arch:any to Arch:all, the question was easily answered by the existence or non-existence of the binary package. Then, when we added the provides, we could use them to answer this question. As we remove the provides, there is no metadata-driven answer to this question anymore. This is not an urgent matter from my side, but it still is one I would like to see a solution for eventually. As far as I understand things, the removal of provides is meant to go back to a working state and then let discussion resume. If we end up reinstating them (in combination with other changes), my use case will be solved again. If the provides are to be removed permanently, I'd like to see a different way of answering the question. Thanks for considering Helmut
