Re: Question about Multi-Arch specifier on Arch: all packages
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.
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.
When that happens, :native suddenly becomes meaningful. This hasn't
bothered us deep enough thus far to seriously consider changing these
(odd) semantics though.
Helmut
Reply to: