Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #83915

Bug#1065416: Bastian's offer in #1065416

Cross-posted to 2 groups.

Show all headers | View raw

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

Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bastian's offer in #1065416 Sean Whitton <spwhitton@spwhitton.name> - 2024-08-17 06:10 +0200
  Re: Bug#1065416: Bastian's offer in #1065416 Stefano Rivera <stefanor@debian.org> - 2024-09-04 15:40 +0200
    Re: Bug#1065416: Bastian's offer in #1065416 Ben Hutchings <benh@debian.org> - 2024-09-09 02:20 +0200
      Re: Bug#1065416: Bastian's offer in #1065416 Ben Hutchings <benh@debian.org> - 2024-09-12 00:40 +0200
        Re: Bug#1065416: Bastian's offer in #1065416 stefanor@debian.org - 2024-09-12 12:00 +0200
          Re: Bug#1065416: Bastian's offer in #1065416 Matthias Klose <doko@debian.org> - 2024-09-15 14:10 +0200
        Bug#1065416: Bastian's offer in #1065416 Helmut Grohne <helmut@subdivi.de> - 2024-09-12 14:40 +0200
          Bug#1065416: Bastian's offer in #1065416 Ben Hutchings <benh@debian.org> - 2024-09-12 20:10 +0200
            Bug#1065416: Bastian's offer in #1065416 Helmut Grohne <helmut@subdivi.de> - 2024-09-14 12:00 +0200
            Bug#1065416: Bastian's offer in #1065416 Matthias Klose <doko@debian.org> - 2024-09-15 14:00 +0200
              Bug#1065416: Bastian's offer in #1065416 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2024-09-15 16:50 +0200
        Re: Bug#1065416: Bastian's offer in #1065416 Ben Hutchings <benh@debian.org> - 2024-09-19 22:10 +0200
          Bug#1065416: Bastian's offer in #1065416 Stefano Rivera <stefanor@debian.org> - 2024-11-28 22:10 +0100
            Bug#1065416: Bastian's offer in #1065416 Ben Hutchings <benh@debian.org> - 2024-11-30 22:20 +0100
            Bug#1065416: Bastian's offer in #1065416 Stefano Rivera <stefanor@debian.org> - 2025-01-28 00:50 +0100

csiph-web