Hello Helmut,
I spoke to Russ and we're both of the view that we should document
multiarch piecemeal. Let's begin by getting a definition of the
Multi-Arch: field into ch. 5 of policy.
I have pushed a new branch to the Debian policy repo named
bug749826-spwhitton. On that branch I've committed a slightly reworked
form of your draft text.[1] Please review the diff. Here are some
comments/issues:
- I substantially shortened your text. Let me know if you think I went
too far.
- Previously I was worried about defining 'interface' but I've found
another place where policy uses this word without defining it, and I
don't think it needs to be changed in either place.
- I couldn't figure out how to include this text, because I didn't
understand it:
For instance, using dpkg --print-architecture can be used to emit the
native architecture even though dpkg is marked Multi-Arch:
foreign. Similarly, calling pkg-config (without a prefix) will behave
differently on different architectures as its search path is
architecture-dependent even thoug pkg-config is marked Multi-Arch:
foreign.
Are you saying that packages that depend or implicitly depend on dpkg
or pkg-config cannot be Multi-arch: foreign, although dpkg and
pkg-config themselves are Multi-arch: foreign? Why are dpkg and
pkg-config Multi-arch: foreign, if they provide these
architecture-dependent interfaces?
- I didn't include your TODO about README.multiarch; let me know whether
you have a more concrete idea about the purpose of that file
- after we've got text documenting the other possible values of the
Multi-Arch: field, we might want to promote the list of things to
consider out of the Multi-Arch: foreign subsubsection. It should
become clear once we've got that other text together.
Thank you again for your work so far.
[1] https://wiki.debian.org/DependencyHell#Multi-Arch:_foreign
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature