Re: Question about Multi-Arch specifier on Arch: all packages
On Wed, 2024-01-17 at 21:01 +0100, Helmut Grohne wrote:
> Hi,
>
> On Wed, Jan 17, 2024 at 08:55:15AM +0000, MOESSBAUER, Felix wrote:
> > I observed a strange dependency issue between the following
> > packages:
> > The efibootguard package depends on python3-shtab and uses Build-
> > Depends: python3-shtab:native to have cross compilation support.
> >
> > However, I recently added the Multi-Arch: foreign tag in python3-
> > shtab
> > [1], which broke the efibootguard package (as this depends python3-
> > shtab:native) and this dependency could not be resolved anymore.
>
> The situation you are observing is recurrent.
>
> > Now I'm wondering if Multi-Arch specifiers should be set at all on
> > Architecture: all packages. I also don't understand why this broke
> > the
> > dependency chain, as my under standing of the Multi-Arch: foreign
> > is
> > based on this statement:
> >
> > > The package is not co-installable and should be allowed to
> > > satisfy
> > the dependencies of a package of another architecture than its own.
> > [2]
>
> The :native annotation is supposed to select a build architecture
> instance of a package. When added to a package that is marked
> Multi-Arch: foreign, this annotation does not make sense, because the
> foreign annotation basically says that the architecture does not
> matter.
> dpkg enforces this in disallowing :native annotations on packages
> marked
> Multi-Arch: foreign. This choice is questionable, because it makes
> adding Multi-Arch: foreign more difficult as you observed. For this
> reason, I recommend to use :native annotations sparingly and always
> check whether instead the target of the dependency can become
> M-A:foreign instead. Such checking has evidently not been done for
> efibootguard. Hence, it now FTBFS as a result of python3-shtab having
> rightly become Multi-Arch: foreign. efibootguard now needs to drop
> the
> :native annotation.
Hi, thanks for the quick reply.
I agree, this is questionable and should at least be documented. For me
it looks more like an implementation aspect, than something that is
documented in the mulitarch spec.
>
> In principle, we could allow :native annotations on M-A:foreign
> packages
> and consider such dependencies satisfied if they are satisfied
> without
> :native. The only downside I see with this is failing to clean up
> those
> unnecessary :native annotations. But then a package that is M-
> A:foreign
> today can become M-A:same tomorrow. This has happened to e.g.
> pkgconf.
The problem hereby is that you need to update both packages in a
lockstep, which is rather unfortunate.
> When that happens, :native suddenly becomes meaningful. This hasn't
> bothered us deep enough thus far to seriously consider changing these
> (odd) semantics though.
I quickly inspected some Architecture: all packages and basically none
of them had multiarch specifiers. So the problem is probably bigger
than expected. I'm wondering if there is a *technical* reason to not
assume Multi-Arch: foreign on Arch:all packages? These anyways can only
be installed once, so only this exact instance of a package is able to
fulfill a dependency.
Felix
>
> Helmut
>
--
Siemens AG, Technology
Linux Expert Center
Reply to: