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

Groups > linux.debian.bugs.dist > #1222762 > unrolled thread

Bug#1084908: arch:all linux-libc-dev causes problems to architecture bootstrap

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1084908: arch:all linux-libc-dev causes problems to architecture bootstrap Bastian Blank <waldi@debian.org> - 2024-12-04 23:00 +0100
    Bug#1084908: arch:all linux-libc-dev causes problems to architecture bootstrap Helmut Grohne <helmut@subdivi.de> - 2024-12-05 13:10 +0100
      Bug#1084908: arch:all linux-libc-dev causes problems to architecture bootstrap Bastian Blank <waldi@debian.org> - 2024-12-05 15:40 +0100
        Bug#1084908: arch:all linux-libc-dev causes problems to architecture bootstrap Helmut Grohne <helmut@subdivi.de> - 2024-12-05 22:30 +0100

#1222762 — Bug#1084908: arch:all linux-libc-dev causes problems to architecture bootstrap

On Thu, Oct 24, 2024 at 01:29:31AM +0200, Ben Hutchings wrote:
> On Sat, 2024-10-19 at 15:35 +0200, Bastian Blank wrote:
> > I have to disagree.  With this setup, we can support architectures that
> > are neither known by dpkg nor dak.  This was not possible before and
> > required patching, aka making a derivative of the package.  You can
> > still patch and rebuild it how you want and inject that modified package
> > into your workflow.
> Currently gencontrol.py runs dpkg-architecture to find the multiarch
> triplet for each Debian architecture.  So it's not possible to add any
> architecture that's unknown to dpkg in unstable.
> Are you proposing to extend our config schema so we can define those
> triplets within src:linux?

I did add that support first.

> Do we really want to be on the critical path for the early stages of
> defining a new architecture, including any renaming that might happen
> before it's added to dpkg upstream?

Which early stages?  We have three stages:
- Before the arch reaches anything related to Debian.  In this stage, it
  does not matter if the package it all or any, it can be patched.
- While it lives on -ports, but dak does not know about it.  In this
  stage, the package needs to be managed manually.
- While it lived on -ports and dak knows about.  In this stage, support
  can be added as arch:any.

Bastian

-- 
... The prejudices people feel about each other disappear when they get
to know each other.
		-- Kirk, "Elaan of Troyius", stardate 4372.5

[toc] | [next] | [standalone]

#1222805

Hi Bastian,

On Wed, Dec 04, 2024 at 10:40:59PM +0100, Bastian Blank wrote:
> On Thu, Oct 24, 2024 at 01:29:31AM +0200, Ben Hutchings wrote:
> > Do we really want to be on the critical path for the early stages of
> > defining a new architecture, including any renaming that might happen
> > before it's added to dpkg upstream?
> 
> Which early stages?  We have three stages:
> - Before the arch reaches anything related to Debian.  In this stage, it
>   does not matter if the package it all or any, it can be patched.

This is the stage I am concerned about. You claim that it would not
matter whether the package is all or any, but my experience is
otherwise. With the exception of linux, the cross bootstrap tooling does
not build any Arch:all packages at all. Adding that support has not been
trivial and the way it is implemented still is violating internal
principles making its code fragile. In particular, for each combination
of package name and architecture, there would only be one binary package
- with the exception of linux where the would now be two (the unpatched
one from the archive and the patched one). I'd have to somehow remove
linux-libc-dev from an unstable amd64 mirror.

The all versus any also poses the problem that it becomes unclear
whether it has to be rebuilt. When it was :any, it always had to be
built, but given that its M-A:foreign is a lie and that we had to remove
the Provides, it is difficult to tell whether a rebuild is needed.

In now find it all surprising that we (at least Ben, Bastian and me)
agree on patching linux at this stage being the right approach. My
earlier impression was that Bastian preferred src:linux to participate
in this early stage of the bootstrap and I have expended mails to argue
otherwise, but that seems unnecessary now.

Instead, the question becomes how we can make that patching easy and the
disagreement becomes whether Arch:all makes that sufficiently easy. Even
though I cite building Arch:all as difficult in the bootstrap context,
the more pressing issue from my side is the inability to tell whether a
rebuild is needed by looking at package relations. Dealing with
unsatisfiable dependencies is something, I've developed ways to deal
with. Dealing with wrongly satisfied dependencies is a totally different
thing to me. As it stands, linux currently is the only package involved
in architecture cross bootstrap that produces false positives in
dependency satisfiability tests used for scheduling builds.

> - While it lives on -ports, but dak does not know about it.  In this
>   stage, the package needs to be managed manually.
> - While it lived on -ports and dak knows about.  In this stage, support
>   can be added as arch:any.

As an architecture enters -ports for the first time, it must have its
triplet included in dpkg. At that time, I think it is reasonable to ask
src:linux to include its headers. linux also is uploaded so frequently
that it will not be practically blocking any port progress. The step
that usually takes much time and convincing is getting an architecture
into dpkg. I do not see an Arch:all linux-libc-dev as being a hindrance
to these later stages.

Helmut

[toc] | [prev] | [next] | [standalone]

#1222812

On Thu, Dec 05, 2024 at 08:38:35AM +0100, Helmut Grohne wrote:
> This is the stage I am concerned about. You claim that it would not
> matter whether the package is all or any, but my experience is
> otherwise. With the exception of linux, the cross bootstrap tooling does
> not build any Arch:all packages at all. Adding that support has not been
> trivial and the way it is implemented still is violating internal
> principles making its code fragile. In particular, for each combination
> of package name and architecture, there would only be one binary package
> - with the exception of linux where the would now be two (the unpatched
> one from the archive and the patched one). I'd have to somehow remove
> linux-libc-dev from an unstable amd64 mirror.

So this tooling does
- patch the source,
- _not_ change the version,
- build non-all?

This sounds broken, as it already relies on those packages producing
compatible all/non-all packages from two different sources.  Yes, in
practice this will work.

To make the double package problem easier, just change the version with
a sufficiently high epoch?

> Instead, the question becomes how we can make that patching easy and the
> disagreement becomes whether Arch:all makes that sufficiently easy. Even
> though I cite building Arch:all as difficult in the bootstrap context,
> the more pressing issue from my side is the inability to tell whether a
> rebuild is needed by looking at package relations. Dealing with
> unsatisfiable dependencies is something, I've developed ways to deal
> with. Dealing with wrongly satisfied dependencies is a totally different
> thing to me. As it stands, linux currently is the only package involved
> in architecture cross bootstrap that produces false positives in
> dependency satisfiability tests used for scheduling builds.

What kind of information can this dependency satisfiability test use?

Something like this?

| Provides:
|   linux-libc-dev-supports (= amd64-0),
|   linux-libc-dev-supports (= arm64-0),
|   linux-libc-dev-supports-multiarch (= aarch64-linux-gnu-0),
|   linux-libc-dev-supports-multiarch (= x86-64-linux-gnu-0),

Bastian

-- 
Vulcans worship peace above all.
		-- McCoy, "Return to Tomorrow", stardate 4768.3

[toc] | [prev] | [next] | [standalone]

#1222865

Hi Bastian,

On Thu, Dec 05, 2024 at 03:30:53PM +0100, Bastian Blank wrote:
> What kind of information can this dependency satisfiability test use?
> 
> Something like this?
> 
> | Provides:
> |   linux-libc-dev-supports (= amd64-0),
> |   linux-libc-dev-supports (= arm64-0),
> |   linux-libc-dev-supports-multiarch (= aarch64-linux-gnu-0),
> |   linux-libc-dev-supports-multiarch (= x86-64-linux-gnu-0),

Using Provides is the natural approach indeed. Encoding the architecture
into the version may technically work, but it feels really strange.
Earlier, I proposed encoding it into the provided package name like
linux-libc-dev-arm64-cross, but we all know how that went and I would
not have proposed it if I had seen how it broke other pieces. Still if
we were to just drop the "-cross" suffix and go for a very similar
version.

Provides: linux-libc-dev-amd64, linux-libc-dev-arm64, ...

In any of these cases, I can inject extra dependencies and have
dose-builddebcheck correctly determine whether the existing
linux-libc-dev satisfies what is needed.

As stated elsewhere, I still don't understand what we gained by
switching from Arch:any to Arch:all, but maybe I don't have to. A
solution that adds any of these Provides is what I'd call good enough in
practical terms for the purpose of bootstrapping.

Helmut

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web