Hi,
thank you Nilesh for getting this started.
On Sun, May 10, 2026 at 03:39:38PM +0100, Sean Whitton wrote:
> Nilesh Patra [10/May 1:04pm +0530] wrote:
> > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> > index 69467c4..f4d5fe9 100644
> > --- a/policy/ch-controlfields.rst
> > +++ b/policy/ch-controlfields.rst
> > @@ -1381,8 +1381,10 @@ A Debian installation can combine packages from
> > multiple architectures.
> > The ``Multi-Arch`` field enables individual packages to declare their
> > support for this feature, and influences the way dependencies are
> > handled. It can be declared in binary package sections of a source
> > -package template control file and in binary package control files. The
> > -permitted field values are ``no`` (default), ``foreign``, ``same`` and
> > +package template control file and in binary package control files.
> > +``Multi-Arch`` must not be used for udebs, as these semantics are out
> > +of scope for the Debian installer.
> > +The permitted field values are ``no`` (default), ``foreign``, ``same`` and
> > ``allowed``. Their semantics are described in the following sections.
> >
> > .. _s-f-Multi-Arch-no:
>
> Thanks. Helmut, do you agree with using a "must not" here?
Generally, I agree with the intent of this change. I do not anticipate
any use of Multi-Arch in the installer. In particular, the way it is
built does not consider this field in any way.
Now "must not" is strong for a field that is ignored. I checked the
amd64 main Packages file and the "must not" would render at least 9 font
packages rc-buggy. Their use of this field presently does not cause
immediate problems as far as I can see.
I kinda like the way this is expressed for the Standards-Version:
udebs and source packages that only produce udebs do not use
Standards-Version.
How about borrowing the wording there?
I am hesitant to second the "must not" precisely for those font
packages.
Helmut
