Re: Question about Multi-Arch specifier on Arch: all packages
Hi,
On 2024-01-18 09:12, MOESSBAUER, Felix wrote:
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.
the original multi-arch [spec] is far from covering all the things. Even
today, 15 years later, we still discover situations where it is not
immediately clear, what the correct course of action should be. Bug
#1030223 is an example of that. Before that, we didn't have the
situation where a :any relationship was declared on a virtual package
where its real provider was marked Multi-Arch:allowed. Thus, [britney]
had to be fixed first.
[spec] https://wiki.ubuntu.com/MultiarchSpec
[britney]
https://salsa.debian.org/release-team/britney2/-/commit/e11262c60fbd06035c64bccba6312c9dc0b56002
Even after all this time we still failed to document multi-arch at least
a little bit in policy (see bug #749826 for details). An attempt is made
to integrate a more detailed spec than the original ubuntu spec in
[dpkg]. In that document you will find a table which indeed documents
that the situation you are facing is not considered to be allowed.
[dpkg]
https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/tree/doc/spec/multiarch.txt?h=pu/doc-multiarch-spec
Another good resource on the matter are the cross-build packaging
guidelines in the debian [wiki]. That page also describes the situation
you are facing including the recommendations that Helmut gave in his
last mail.
[wiki] https://wiki.debian.org/CrossBuildPackagingGuidelines
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.
I think I remember that I had written this up on another wiki page at
some point but I probably misremember. I should write this down. This
question is also a popular one.
Yes, in this case, there is a clear technical reason why arch:all are
not implicitly treated as m-a:foreign. The arch:all annotation is about
the *contents* of a package. It means that no matter on what
architecture you install the package, its contents remain the same. So
by marking it as arch:all we only build the package once and then
install the same copy everywhere. In contrast, the m-a:foreign marking
is about the interface of the package. If you mark a package as
m-a:foreign, then that means that whatever it does as part of what is
considered its interface is the same independent on the architecture.
For example, the tool `grep` is marked as m-a:foreign because
independent of its architecture, the tool will (hopefully) do the same
thing independent of its architecture. But this is not necessarily the
case for an arch:all package. Imagine an arch:all package containing
just a simple shell script. Since it's a shell script, the package is
certainly the same on all architectures, so we can mark it arch:all. But
now let this shell script call gcc or uname or any other tool that does
architecture-specific stuff. Now your shell script does something
different on different architectures even though the script itself is
the same everywhere.
And yes, there are very many arch:all packages that have been marked
m-a:foreign. You can use this command to find them:
grep-aptavail -X \( -F Multi-Arch foreign -a -F Architecture all \) -s
Package -n
Thanks!
cheers, josch
Reply to: