Hello Helmut,
On Mon, Sep 04 2017, Helmut Grohne wrote:
> 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.
I see what you mean.
I find the terminology "intended interface" confusing: if something is
not intended as an interface, then it is simply not an interface. The
interfaces of a package are up to its maintainer.
I just pushed a commit using this text, which gets around this issue;
let me know what you think:
The interfaces of a package are determined by its maintainer.
However, some packages might expose architecture dependencies when
other packages use them in a manner not intended by the maintainer.
This can happen when it is not clear which parts of the package are
its interfaces.
In such cases, where the package satisfies the criterion for
``Multi-Arch: foreign`` but might expose architecture dependency
because it is not clear which parts of the package are its
interfaces, the interfaces of the package should be described in the
file ``debian/README.multiarch``.
>> 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.
I don't think Policy should be silent about this. I have pushed a
commit adding a footnote which notes that libc6 is not expected to be in
compliance.
>> > * 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.
Is this a problem? Don't we usually binNMU in such a situation?
> That definition is pretty annoying for bootstraps though as
> replicating ancient toolchain is kinda the opposite of what
> bootstrappers do.
I'm not sure what you mean. My suggestion is that we say it should
match what's in the suite right now -- /not/ any ancient toolchain.
>> 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.
Thanks! Applied, and then followed up with a commit tweaking wording.
> As Simon's mail demonstrates, we likely need more answers/consensus
> before continuing. I'll reply in a separate mail.
Do these remaining issues affect our definitions of the `foreign` and
`no` values, or only the definitions for the other possible values?
If we are finished with our definitions for `no` and `foreign`, I think
it would be worth releasing them in Policy, of course with a caveat
saying "there are other possible values". I say this as a package
maintainer would has benefitted from reading your descriptions of
`foreign` and `no`. These are useful and should be out there.
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature