Hello Helmut, On Sun, Aug 20 2017, Helmut Grohne wrote:
>> - 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?
>
> Those are very good questions and clarifying them will lead to a better
> understanding of what we have to put into policy. You do understand that
> "dpkg --print-architecture" is part of dpkg's interface. Yet its out
> varies with its architecture. Taking this strictly would indeed imply
> that dpkg is wrongly marked. Similarly, running pkg-config may result in
> architecture-dependent paths and thus our strict interpretation would
> result in rejecting the foreign marking.
>
> A common theme with such cases is to resort to `Multi-Arch: allowed`
> (e.g. make), but that has the downside of requiring most consumers to
> attach the :any annotation and that it can never be switched back
> (because :any dependencies on packages not marked M-A:allowed are
> unsatisfiable).
>
> This is where I thought about README.multiarch:
>
>> - 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
>
> It can document assumptions one makes about users of a package. For
> instance, we expect dpkg users to use `dpkg --print-architecture`
> diagnostically only. Similarly, we expect that package builds call
> pkg-config if they mean the build architecture and they need to call
> $(DEB_HOST_GNU_TYPE)-pkg-config if they mean the host architecture.
> Indeed that happens automatically for autotools projects that happen to
> use PKG_CHECK_MODULES or PKG_PROG_PKG_CONFIG (i.e. most). It also
> happens for cmake when built with dh_auto_build.
>
> Let me give a counter example to illustrate more of the point.
> haskell-devscripts-minimal is an `Architecture: all` package with some
> shell scripts. Sounds like a good candidate for `Multi-Arch: foreign`.
> When you look at /usr/share/haskell-devscripts/Dh_Haskell.sh though, you
> see that functions such as cpu(), os(), etc. specifically introspect the
> build architecture by using the build architecture ghc. Such usage is
> not ok for `Multi-Arch: foreign` (#769377).
>
> I believe that policy should encourage some uniform way to document the
> intended interface as we have several cases where this is not obvious.
> README.multiarch may be that way. In particular, using a package in a
> way not permitted by such README.multiarch would need to be a policy
> violation on its own. For instance, one could depend on a shared library
> and declare it an implementation detail. Relying on the transitive
> dependency would then be considered a policy violation.
Rather than introduce the new terminology 'intended interface', which we
would definitely have to define, how about something like this:
If all a package's architecture-dependent interfaces are listed in
README.multiarch, the package is not considered to have any
architecture-dependent interfaces for the purposes of determining
whether it may be labelled Multi-Arch: foreign.
Then we have a separate section explaining what to put in
README.multiarch, and explaining how depending package maintainers
must respond to the information in 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.
>
> Indeed, documenting `Multi-Arch: same` may be easier (or not). For the
> purpose of defining it, we shall call Debian binary packages for
> different architectures with equal binary package name and version
> "instances" of a package. I currently see the following requirements:
>
> * It must not be used on `Architecture: all` packages (though I wish
> you could ;).
>
> * Given any two instances of a package and any filename, that filename
> must be non-existent in at least one package or the type (directory /
> regular file / etc.) must match and when the filename refers to a
> regular file, the contents must be bitwise equal in both instances.
>
> This point deserves some more thought as it has some pitfalls:
>
> * If there is such a conflict, but the relevant packages are not
> coinstallable due to package relations, is that ok? Example: libc6
> has such a conflict on /lib/ld.so.1 for mips and mipsel.
> (Presently, you get an unpack error here.)
If libc6's use is legitimate then it seems we'd need to include this as
an exception.
> * If you rebuild the source package with a very different
> installation set (i.e. much newer Build-Depends), does it still
> have to match with older instances? Example: #825146. What
> divergence in installation sets is ok?
We could just say that it must match the instances in the target suite.
> (A simple way to satisfy this requirement is to use
> architecture-dependent paths exclusively. That works except for
> /usr/share/doc/$pkg.)
>
> * The maintainer scripts must handle multiple configuration and
> multiple deconfiguration correctly. In particular, a package can be
> purged for one architecture while being installed for another.
> Example: #682420.
>
> (A simple way to satisfy this requirement is to not ship maintainer
> scripts.)
>
> * Source packages carrying any binary package marked `Multi-Arch: same`
> must always be binNMUed in lock-step. (Presently violated e.g. by
> libselinux1)
Could you turn this into some commits against my branch, please?
> Ah right and you asked for a review of the branch. ;)
>
> I think "the files installed by ``Architecture: all`` packages always
> provide architecture-independent interfaces." is too broad. The counter
> example is haskell-devscripts-minimal. This needs to be weakened
> somehow.
It sounds like we need to just drop the whole bullet point.
Architecture: all packages need to be checked carefully, just like
Architecture: any packages.
> Your shortening of my draft has significantly cut precision and
> improved readability. It is difficult to strike a useful balance here
> and I am certainly biased towards precision. I'm unsure how to proceed
> here. I believe that your current form will cause discussion and
> dispute among policy readers. For instance, the policy should make it
> clear that marking libmdds-dev `Multi-Arch: foreign` (fictional, see
> #843023) would be a policy violation.
>
> So the current text falls short on objections e.g. Bill Allombert raised
> on the reproducible issue: Can I mechanically check policy requirements?
> It is actually worse here: Given a Multi-Arch bug report, it is
> difficult to determine whether your draft supports it due to the lack of
> precision.
Right.
To my mind, the most important ways to achieve readability in this case
are
- avoid repetition
- avoid "probably", "likely" sentences.
When I cut down your draft I was trying to remove repetition. After
reading your e-mail, I now see that not all of it was actually
repetition. Could you make some commits against my branch adding the
information that was not repeated, please?
--
Sean Whitton
signature.asc
Description: PGP signature
