Groups | Search | Server Info | Login | Register

Groups > linux.debian.policy > #6007

Bug#749826: Documenting `Multi-Arch: foreign`

Cross-posted to 2 groups.

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On Sat, Sep 02, 2017 at 08:44:14AM -0700, Sean Whitton wrote:
> 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.

This is not how it works. It's not like you can just mark any package
Multi-Arch: foreign after saying that it is architecture-dependent. That
documentation must come with a contract saying that reverse dependencies
must not use those architecture-dependent interfaces.

> If libc6's use is legitimate then it seems we'd need to include this as
> an exception.

Well, it's not exactly legitimate. It's more like unavoidable as Simon
pointed out in his reply. Technically, libc6's behaviour is wrong and
causes unpack errors. The reasonable solution would be prohibiting
coinstallation of libc6:mips and libc6:mipsel, but package metadata does
not allow us to do that currently (#747261 -> self-conflicts are always
ignored). The other option of removing Multi-Arch: same from libc6 would
essentially render Multi-Arch useless. So all we can do now is pretend
the issue wasn't there.

> >     * 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.

We could. That would render libgiac0 rc buggy for instance, because it
was built on mips64el three weeks later than on other architectures and
thus uses an incompatible gettext.

That definition is pretty annoying for bootstraps though as replicating
ancient toolchain is kinda the opposite of what bootstrappers do.

> >    (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?

I tried and ran into a new problem: I am now convinced that we cannot
just describe one Multi-Arch value after another as they do share some
common values. That "interface" aspect and architecture-constraints on
dependencies is a common theme and likely deserves an introductory text.

Yet, I am attaching what I have.

> 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.

Reworded.

> To my mind, the most important ways to achieve readability in this case
> are
> 
> - avoid repetition
> - avoid "probably", "likely" sentences.

The latter is particularly hard, because we violate the strict
definitions more often than is immediately apparent.

As Simon's mail demonstrates, we likely need more answers/consensus
before continuing. I'll reply in a separate mail.

Helmut

Back to linux.debian.policy | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Bug#749826: Documenting `Multi-Arch: foreign` Sean Whitton <spwhitton@spwhitton.name> - 2017-08-20 20:10 +0200
  Bug#749826: Documenting `Multi-Arch: foreign` Helmut Grohne <helmut@subdivi.de> - 2017-08-20 23:10 +0200
    Bug#749826: Documenting `Multi-Arch: foreign` Sean Whitton <spwhitton@spwhitton.name> - 2017-09-02 17:50 +0200
      Bug#749826: Documenting `Multi-Arch: foreign` Simon McVittie <smcv@debian.org> - 2017-09-02 18:40 +0200
        Bug#749826: Documenting `Multi-Arch: foreign` Helmut Grohne <helmut@subdivi.de> - 2017-09-04 23:20 +0200
      Bug#749826: Documenting `Multi-Arch: foreign` Helmut Grohne <helmut@subdivi.de> - 2017-09-04 23:20 +0200
        Bug#749826: Documenting `Multi-Arch: foreign` Sean Whitton <spwhitton@spwhitton.name> - 2017-10-15 00:00 +0200

csiph-web