Hi Andrea, I put Patrick in CC to resolve this misunderstanding. Quoting Andrea Pappacoda (2024-09-22 13:07:41) > I've always thought that adding Multi-Arch: foreign to Architecture: any > binaries was somewhat trivial in most cases. For example, if I have > a C program which converts Markdown into HTML I can set it MA:foreign > since of course its behaviour is the same regardless of its > architecture. > > And that's how I've always approached this. In essence your understanding is correct. In practice, in my opinion, the concepts of and behind Multi-Arch:foreign are the hardest bit of multiarch to grok and it's not always quite obvious. In the case of a program which converts markdown to html and does not do any other magic besides that, the answer is luckily on the more obvious side. > A couple of days ago, though, I've had an interesting discussion with > Patrick Franz (delta-one) about this exact topic: setting MA:foreign for > the md2html package (currently in NEW). You can find the full discussion > at > <https://salsa.debian.org/qt-kde-team/3rdparty/md4c/-/merge_requests/3>, > but I'll try to summarize it here. > > In short, Patrick makes this interesting argument, which I find somewhat > unlikely but still valid: > > > Assume that package foo depends on md2html and md2html is marked as > > M-A:foreign. That would mean that you can install md2html:s390x on > > your system and it would satisfy foo's dependencies because md2html > > satisfies the dependencies of any architechture. As you correctly > > pointed out, you cannot run md2html:s390x on your amd64 system but if > > marked M-A:foreign you're saying it's fine to do so. > > I'd recommend to read the full thread on the merge request to get the > full picture. It isn't that long. > > Why isn't this an issue? Or am I fundamentally misunderstanding how > Multi-Arch: foreign works? I've now read the conversation. There are a few misunderstandings in it. > Oh yes, it'll likely build on any architecture. But it's an architecture > dependent binary, so it shouldn't be MA: foreign. This conclusion is not correct. It is perfectly fine for Arch:any packages to be Multi-Arch:foreign. The "foreign" value denotes, that independent on what architecture a package has, its interface remains the same. > It's actually common to use M-A:same for libs and M-A:foreign for Arch:all > packages. Nothing says that you have to provide that field and it's quite > uncommon that application packages with binaries even provide it. That is correct. Packages do not have to provide that field. Many (most?) applications exhibit architecture-dependent behaviour, so it would be wrong to mark them with M-A:foreign. > Let's take your cross example: You're running an amd64 system and you want to > install/use package foo. Assume that package foo depends on mdhtml and mdhtml > is marked as M-A:foreign. That would mean that you can install mdhtml:s390x > on your system and it would satisfy foo's dependencies because mdhtml > satisfies the dependencies of any architechture. That is correct. If mdhtml would be M-A:foreign, it would satisfy that dependency. And of course it would be unrunnable. But those are two orthogonal concepts. Let make another example: suppose you are on amd64 and then you install mdhtml:i386. Even though you are on amd64, you can run this. Or lets go back to your s390x example. Now you install the qemu-user package and magically the foreign architecture package becomes executable. What I want to point out here: what architecture your system can run/execute is not related to the Multi-Arch field your package has. Those are two very different things. In fact, to not run into this situation, package builders like sbuild have to be careful to not allow apt installing foreign architecture M-A:foreign packages. Source: I wrote that code. > As you correctly pointed out, you cannot run mdhtml:s390x on your amd64 > system but if marked M-A:foreign you're saying it's fine to do so. No. Multi-Arch:foreign does not mean "this binary can run anywhere" if it would mean that, why are not all Arch:all packages marked with it? And if it would mean that? Why do we need the field at all? Or: why are then so many Arch:any packages marked M-A:foreign? Are they all buggy and an MBF is needed? No, it is perfectly fine to mark an Arch:any package with M-A:foreign if its intended interface is architecture independent. A lot of packages in the archive do this correctly. The Multi-Arch field does *not* specify what architecture your system is able to run either natively or with QEMU support. More information on this topic: https://wiki.debian.org/DependencyHell#Multi-Arch:_foreign A converter from markdown to html indeed sounds like one of the most trivial examples where the M-A:foreign marking would be correct independent on whether that converter is a compiled binary or written in a scripting language. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature