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

Bastien Roucaries <[email protected]> Tue, 17 Mar 2026 08:49:08 +0100
Newsgroups	gmane.linux.debian.devel.policy
Message-ID	<1953228.tdWV9SEqCh__2964.55627992458$1773733885$gmane$org@debian-ei>
Le mercredi 25 février 2026, 22:20:09 heure normale d’Europe centrale Sean Whitton a écrit :
Hello Helmut, Hello natie,
> Hello Helmut,
> 
> Thanks for the updated patch.  I have just three remaining changes I'd
> like to ask you to make:
> 
> Helmut Grohne [09/Jul  7:14pm +02] wrote:
> >> > +- The installed files of a package: Architecture-dependent packages may
> >> > +  install different sets of files or files with different content for
> >> > +  multiple architectures and these differences may contribute to the
> >>
> >> s/multiple/different/
> >
> > Yes, thanks.
> 
> Here you did s/different/multiple/ instead.  Can you change both
> 'multiple's to 'different'?
> 
> >> > In particular, ``postrm`` must consider
> >> > +  that another instance may still be present.
> >>
> >> How about:
> >>
> >>     In particular, any ``postrm`` script must not assume that all
> >>     instances of the package (i.e., instances for other architectures)
> >>     are all gone.
> >
> > I don't see what aspect you are improving here and prefer the existing
> > wording, because it is more focused on the key aspect. That said, "may"
> > is not the right term there.
> 
> I think that "another instance may still be present" is strange.
> Up to this point in the text we haven't been using "instance" to mean:
> packages of the same name but for different architectures.
> Therefore it feels like the reader has to guess that this is what
> "instance" means here.  My suggested wording avoids that problem.
> 
> >> > +This value should be used rarely for cases where the package can be used
> >> > +in an architecture-dependent way or in an architecture-independent way
> >> > +and the decision of which applies is deferred to the depender. The most
> >> > +common use is with programming language interpreters that enable loading
> >> > +architecture-dependent plugins.
> >>
> >> Can you avoid "should" here?  I don't think you intend to be normative.
> >
> > Unless I misunderstand "should", that particular normative is intended
> > here. I was even considering that usage of allowed must be discussed
> > with d-devel beforehand just like the use of epochs.
> 
> There seem to be two possible normative requirements:
> - if the package can be used in an architecture-dependent way or an
>   architecture-independent way and it's up to the depender, then you
>   should use multi-arch:allowed
> - you should not use multi-arch:allowed commonly (where common == !rare)
> 
> Are you really trying to say both?  I think you really want to say:
> - if the package can be used in an arch-dep or arch-indep way and it's
>   up to the depender then you *can* use multi-arch:allowed
> - you should not use multi-arch:allowed commonly
> 
> i.e. just one should.
> 
> If you really do mean both shoulds, then I suggest two sentences/clauses
> with "should" appearing twice.  But that seems strange because for the
> other field values we don't explicitly say that you *should* use this
> value if it applies to your package.  E.g. we don't say "if the
> interfaces the package provides are independent of its architecture you
> *should* use multi-arch:foreign".
> 
> Thanks again, just a few changes and then we can second and push this.

Can you get a final review ?
>
signature.asc (application/pgp-signature, 833 B)