Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
Helmut Grohne [23/Jun 7:03pm +02] wrote: > On Sat, May 23, 2026 at 04:29:50PM +0530, Nilesh Patra wrote: >> I have attached 2 patches, please choose the one that sounds best :) >> >> Please take a look and let me know if this work. Otherwise please >> also tell me if further changes are required. > > The perfect is the enemy of the good and both versions really are > sensible to me. I see there are different preferences, but both are > strictly better than the status quo. Thanks, pushed to the 'next' branch. -- Sean Whitton
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
On Tue, Jun 23, 2026 at 07:03:52PM +0200, Helmut Grohne wrote: > The perfect is the enemy of the good and both versions really are > sensible to me. I see there are different preferences, but both are > strictly better than the status quo. I agree and like Helmut I second both patches quoted below as well. > > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > > index 69467c4..03b1c29 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. > > +The ``Multi-Arch`` field should not be added to the binary package > > +sections for udebs because it does not apply to them. > > +The permitted field values are ``no`` (default), ``foreign``, ``same`` and > > ``allowed``. Their semantics are described in the following sections. > > > > .. _s-f-Multi-Arch-no: > > I second this version. I recognize Guillem's concern, but that does not > lead me to rejecting this version. > > > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > > index 69467c4..124ea96 100644 > > --- a/policy/ch-controlfields.rst > > +++ b/policy/ch-controlfields.rst > > @@ -1381,8 +1381,9 @@ 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. > > +The Multi-Arch field does not apply to udebs and should be omitted. > > +The permitted field values are ``no`` (default), ``foreign``, ``same`` and > > ``allowed``. Their semantics are described in the following sections. > > > > .. _s-f-Multi-Arch-no: > > I also second this version. I suggest s/ Multi-Arch / ``Multi-Arch`` /, > but that is a formatting-only change and does not affect seconds. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Always antifa. signature.asc Description: PGP signature
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
On Sat, May 23, 2026 at 04:29:50PM +0530, Nilesh Patra wrote: > I have attached 2 patches, please choose the one that sounds best :) > > Please take a look and let me know if this work. Otherwise please > also tell me if further changes are required. The perfect is the enemy of the good and both versions really are sensible to me. I see there are different preferences, but both are strictly better than the status quo. > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 69467c4..03b1c29 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. > +The ``Multi-Arch`` field should not be added to the binary package > +sections for udebs because it does not apply to them. > +The permitted field values are ``no`` (default), ``foreign``, ``same`` and > ``allowed``. Their semantics are described in the following sections. > > .. _s-f-Multi-Arch-no: I second this version. I recognize Guillem's concern, but that does not lead me to rejecting this version. > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 69467c4..124ea96 100644 > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst > @@ -1381,8 +1381,9 @@ 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. > +The Multi-Arch field does not apply to udebs and should be omitted. > +The permitted field values are ``no`` (default), ``foreign``, ``same`` and > ``allowed``. Their semantics are described in the following sections. > > .. _s-f-Multi-Arch-no: I also second this version. I suggest s/ Multi-Arch / ``Multi-Arch`` /, but that is a formatting-only change and does not affect seconds. Helmut signature.asc Description: PGP signature
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
Nilesh Patra [23/Jun 8:25pm +0530] wrote: > On 23/06/26 5:58 pm, Sean Whitton wrote: >> Nilesh Patra [23/Jun 12:00am +0530] wrote: >>> Wanted to bubble up this and wished to know where we are on this. >>> >>> Is there a consensus on the preferred wording finally? >> >> Your patch has one second, from me, but needs another. > > There are 2 patches, Guillem seconded the other. Is the wording there > acceptable to you? I think the one I seconded is better. -- Sean Whitton signature.asc Description: PGP signature
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
On 23/06/26 5:58 pm, Sean Whitton wrote: > Nilesh Patra [23/Jun 12:00am +0530] wrote: >> Wanted to bubble up this and wished to know where we are on this. >> >> Is there a consensus on the preferred wording finally? > > Your patch has one second, from me, but needs another. There are 2 patches, Guillem seconded the other. Is the wording there acceptable to you?
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
Nilesh Patra [23/Jun 12:00am +0530] wrote: > Wanted to bubble up this and wished to know where we are on this. > > Is there a consensus on the preferred wording finally? Your patch has one second, from me, but needs another. -- Sean Whitton signature.asc Description: PGP signature
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
Wanted to bubble up this and wished to know where we are on this. Is there a consensus on the preferred wording finally? On 23/05/26 7:51 pm, Guillem Jover wrote: > Hi! > > On Sat, 2026-05-23 at 16:29:50 +0530, Nilesh Patra wrote: >> On 23/05/26 4:16 pm, Sean Whitton wrote: >>> Nilesh Patra [22/May 7:58pm +0530] wrote: Hi Sean, As per discussion on the IRC, we are waiting for you to tell us which wording you'd prefer out of all the iterations. Could you let us know? Consider this a gentle nudge. [18:41:04] feels more like policy editors needing a ping here in the sense that they might pick their preferred wording and we'd just second it [18:53:21] ack, AFAIR the new wording seemed way better, but given that I'm not a native speaker (and the editors are) at this point of nitpicking/wordsmithing, that's what I'd rely on them for :) [19:51:54] I was under the impression that policy editors will pick it up after you folks second it... [19:52:18] I'll just relay this on the bug report >>> >>> Thanks, I didn't realise this was waiting on us. >>> >>> How about putting the 'should' first and the information later: >>> >>> The ``Multi-Arch`` field should not be added to the binary package >>> sections for udebs because it does not apply to them. >> >> Done. >> >> I have attached 2 patches, please choose the one that sounds best :) >> >> Please take a look and let me know if this work. Otherwise please >> also tell me if further changes are required. > >> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst >> index 69467c4..03b1c29 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. >> +The ``Multi-Arch`` field should not be added to the binary package >> +sections for udebs because it does not apply to them. >> +The permitted field values are ``no`` (default), ``foreign``, ``same`` and >> ``allowed``. Their semantics are described in the following sections. >> >> .. _s-f-Multi-Arch-no: > > To me this still has the issue I pointed out in an earlier mail. > >> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst >> index 69467c4..124ea96 100644 >> --- a/policy/ch-controlfields.rst >> +++ b/policy/ch-controlfields.rst >> @@ -1381,8 +1381,9 @@ 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. >> +The Multi-Arch field does not apply to udebs and should be omitted. >> +The permitted field values are ``no`` (default), ``foreign``, ``same`` and >> ``allowed``. Their semantics are described in the following sections. >> >> .. _s-f-Multi-Arch-no: >> > > I think I still prefer this formulation (or wording variations conveying > the same). So I'd second this or any wording variations over it. > > Thanks, > Guillem
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
Hi! On Sat, 2026-05-23 at 16:29:50 +0530, Nilesh Patra wrote: > On 23/05/26 4:16 pm, Sean Whitton wrote: > > Nilesh Patra [22/May 7:58pm +0530] wrote: > >> Hi Sean, > >> > >> As per discussion on the IRC, we are waiting for you to tell us which > >> wording > >> you'd prefer out of all the iterations. > >> > >> Could you let us know? Consider this a gentle nudge. > >> > >> [18:41:04] feels more like policy editors needing a ping here in > >> the sense that they might pick their preferred wording and we'd just > >> second it > >> [18:53:21] ack, AFAIR the new wording seemed way better, but > >> given that I'm not a native speaker (and the editors are) at this point of > >> nitpicking/wordsmithing, that's what I'd rely on them for :) > >> [19:51:54] I was under the impression that policy editors > >> will pick it up after you folks second it... > >> [19:52:18] I'll just relay this on the bug report > > > > Thanks, I didn't realise this was waiting on us. > > > > How about putting the 'should' first and the information later: > > > > The ``Multi-Arch`` field should not be added to the binary package > > sections for udebs because it does not apply to them. > > Done. > > I have attached 2 patches, please choose the one that sounds best :) > > Please take a look and let me know if this work. Otherwise please > also tell me if further changes are required. > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 69467c4..03b1c29 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. > +The ``Multi-Arch`` field should not be added to the binary package > +sections for udebs because it does not apply to them. > +The permitted field values are ``no`` (default), ``foreign``, ``same`` and > ``allowed``. Their semantics are described in the following sections. > > .. _s-f-Multi-Arch-no: To me this still has the issue I pointed out in an earlier mail. > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 69467c4..124ea96 100644 > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst > @@ -1381,8 +1381,9 @@ 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. > +The Multi-Arch field does not apply to udebs and should be omitted. > +The permitted field values are ``no`` (default), ``foreign``, ``same`` and > ``allowed``. Their semantics are described in the following sections. > > .. _s-f-Multi-Arch-no: > I think I still prefer this formulation (or wording variations conveying the same). So I'd second this or any wording variations over it. Thanks, Guillem
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
Nilesh Patra [23/May 4:29pm +0530] wrote: > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 69467c4..03b1c29 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. > +The ``Multi-Arch`` field should not be added to the binary package > +sections for udebs because it does not apply to them. > +The permitted field values are ``no`` (default), ``foreign``, ``same`` and > ``allowed``. Their semantics are described in the following sections. > > .. _s-f-Multi-Arch-no: Seconded. -- Sean Whitton signature.asc Description: PGP signature
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
On 23/05/26 4:16 pm, Sean Whitton wrote: > Nilesh Patra [22/May 7:58pm +0530] wrote: >> Hi Sean, >> >> As per discussion on the IRC, we are waiting for you to tell us which wording >> you'd prefer out of all the iterations. >> >> Could you let us know? Consider this a gentle nudge. >> >> [18:41:04] feels more like policy editors needing a ping here in >> the sense that they might pick their preferred wording and we'd just second >> it >> [18:53:21] ack, AFAIR the new wording seemed way better, but given >> that I'm not a native speaker (and the editors are) at this point of >> nitpicking/wordsmithing, that's what I'd rely on them for :) >> [19:51:54] I was under the impression that policy editors >> will pick it up after you folks second it... >> [19:52:18] I'll just relay this on the bug report > > Thanks, I didn't realise this was waiting on us. > > How about putting the 'should' first and the information later: > > The ``Multi-Arch`` field should not be added to the binary package > sections for udebs because it does not apply to them. Done. I have attached 2 patches, please choose the one that sounds best :) Please take a look and let me know if this work. Otherwise please also tell me if further changes are required. diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index 69467c4..03b1c29 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. +The ``Multi-Arch`` field should not be added to the binary package +sections for udebs because it does not apply to them. +The permitted field values are ``no`` (default), ``foreign``, ``same`` and ``allowed``. Their semantics are described in the following sections. .. _s-f-Multi-Arch-no: diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index 69467c4..124ea96 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -1381,8 +1381,9 @@ 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. +The Multi-Arch field does not apply to udebs and should be omitted. +The permitted field values are ``no`` (default), ``foreign``, ``same`` and ``allowed``. Their semantics are described in the following sections. .. _s-f-Multi-Arch-no:
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
Nilesh Patra [22/May 7:58pm +0530] wrote: > Hi Sean, > > As per discussion on the IRC, we are waiting for you to tell us which wording > you'd prefer out of all the iterations. > > Could you let us know? Consider this a gentle nudge. > > [18:41:04] feels more like policy editors needing a ping here in the > sense that they might pick their preferred wording and we'd just second it > [18:53:21] ack, AFAIR the new wording seemed way better, but given > that I'm not a native speaker (and the editors are) at this point of > nitpicking/wordsmithing, that's what I'd rely on them for :) > [19:51:54] I was under the impression that policy editors > will pick it up after you folks second it... > [19:52:18] I'll just relay this on the bug report Thanks, I didn't realise this was waiting on us. How about putting the 'should' first and the information later: The ``Multi-Arch`` field should not be added to the binary package sections for udebs because it does not apply to them. -- Sean Whitton signature.asc Description: PGP signature
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
Hi Sean, As per discussion on the IRC, we are waiting for you to tell us which wording you'd prefer out of all the iterations. Could you let us know? Consider this a gentle nudge. [18:41:04] feels more like policy editors needing a ping here in the sense that they might pick their preferred wording and we'd just second it [18:53:21] ack, AFAIR the new wording seemed way better, but given that I'm not a native speaker (and the editors are) at this point of nitpicking/wordsmithing, that's what I'd rely on them for :) [19:51:54] I was under the impression that policy editors will pick it up after you folks second it... [19:52:18] I'll just relay this on the bug report On 16/05/26 8:24 am, Nilesh Patra wrote: > > > On 16/05/26 8:13 am, Guillem Jover wrote: >>> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst >>> index 69467c4..0f5933c 100644 >>> --- a/policy/ch-controlfields.rst >>> +++ b/policy/ch-controlfields.rst >>> @@ -1381,8 +1381,9 @@ 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. >>> +The ``Multi-Arch`` field does not affect udebs. >>> +The permitted field values are ``no`` (default), ``foreign``, ``same`` and >>> ``allowed``. Their semantics are described in the following sections. >>> >>> .. _s-f-Multi-Arch-no: >> >> I think this is better than the previous iterations, but it feels a >> bit vague, because it describes the effect that Multi-Arch has, which >> then makes not using them implied. Perhaps better to be more explicit >> about it? What about something along the lines of? >> >> "The Multi-Arch field is not relevant for udebs, and should thus not >>be used on them." >> >> Although I feel there's something cumbersome about that phrasing, so >> probably a better wording can be found. > Attached another patch to match the phrasing. Let me know if this could > make the cut :) > > Best, > Nilesh
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
On 16/05/26 8:13 am, Guillem Jover wrote: >> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst >> index 69467c4..0f5933c 100644 >> --- a/policy/ch-controlfields.rst >> +++ b/policy/ch-controlfields.rst >> @@ -1381,8 +1381,9 @@ 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. >> +The ``Multi-Arch`` field does not affect udebs. >> +The permitted field values are ``no`` (default), ``foreign``, ``same`` and >> ``allowed``. Their semantics are described in the following sections. >> >> .. _s-f-Multi-Arch-no: > > I think this is better than the previous iterations, but it feels a > bit vague, because it describes the effect that Multi-Arch has, which > then makes not using them implied. Perhaps better to be more explicit > about it? What about something along the lines of? > > "The Multi-Arch field is not relevant for udebs, and should thus not >be used on them." > > Although I feel there's something cumbersome about that phrasing, so > probably a better wording can be found. Attached another patch to match the phrasing. Let me know if this could make the cut :) Best, Nileshdiff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index 69467c4..124ea96 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -1381,8 +1381,9 @@ 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. +The Multi-Arch field does not apply to udebs and should be omitted. +The permitted field values are ``no`` (default), ``foreign``, ``same`` and ``allowed``. Their semantics are described in the following sections. .. _s-f-Multi-Arch-no:
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
Hi! On Thu, 2026-05-14 at 18:18:36 +0530, Nilesh Patra wrote: > On 14/05/26 9:13 am, Guillem Jover wrote: > > On Wed, 2026-05-13 at 17:49:29 +0530, Nilesh Patra wrote: > >> On 10/05/26 8:46 pm, Helmut Grohne wrote: > > (Also just in case, and to clarify, > > neither Standards-Version nor Multi-Arch fields get inherited.) > > That makes sense, since S-V is not a binary package stanza field, I suppose > nothing to "inherit" here. I was clear about M-A, though. > I did not think clearly before saying otherwise - apologies. No worries, and nothing to apologize for! > >> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > >> index 69467c4..92d4dbe 100644 > >> --- a/policy/ch-controlfields.rst > >> +++ b/policy/ch-controlfields.rst > >> @@ -1381,8 +1381,9 @@ 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. > >> +Binary package stanzas for udebs do not make use of ``Multi-Arch``. > >> +The permitted field values are ``no`` (default), ``foreign``, ``same`` and > >> ``allowed``. Their semantics are described in the following sections. > >> > >> .. _s-f-Multi-Arch-no: > > > > Maybe just say that for udeb packages the field is not > > useful/used/taken-into-account/in-scope? Which should cover not only > > debian/control but also DEBIAN/control (for example via > > «dpkg-gencontrol -DMulti-Arch»)? > > I've tried to re-word it with something else, then :) > Please take a look and see if this is more sensible. > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 69467c4..0f5933c 100644 > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst > @@ -1381,8 +1381,9 @@ 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. > +The ``Multi-Arch`` field does not affect udebs. > +The permitted field values are ``no`` (default), ``foreign``, ``same`` and > ``allowed``. Their semantics are described in the following sections. > > .. _s-f-Multi-Arch-no: I think this is better than the previous iterations, but it feels a bit vague, because it describes the effect that Multi-Arch has, which then makes not using them implied. Perhaps better to be more explicit about it? What about something along the lines of? "The Multi-Arch field is not relevant for udebs, and should thus not be used on them." Although I feel there's something cumbersome about that phrasing, so probably a better wording can be found. Thanks, Guillem
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
On 14/05/26 9:13 am, Guillem Jover wrote: > On Wed, 2026-05-13 at 17:49:29 +0530, Nilesh Patra wrote: >> On 10/05/26 8:46 pm, Helmut Grohne wrote: > (Also just in case, and to clarify, > neither Standards-Version nor Multi-Arch fields get inherited.) That makes sense, since S-V is not a binary package stanza field, I suppose nothing to "inherit" here. I was clear about M-A, though. I did not think clearly before saying otherwise - apologies. >> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst >> index 69467c4..92d4dbe 100644 >> --- a/policy/ch-controlfields.rst >> +++ b/policy/ch-controlfields.rst >> @@ -1381,8 +1381,9 @@ 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. >> +Binary package stanzas for udebs do not make use of ``Multi-Arch``. >> +The permitted field values are ``no`` (default), ``foreign``, ``same`` and >> ``allowed``. Their semantics are described in the following sections. >> >> .. _s-f-Multi-Arch-no: > > Maybe just say that for udeb packages the field is not > useful/used/taken-into-account/in-scope? Which should cover not only > debian/control but also DEBIAN/control (for example via > «dpkg-gencontrol -DMulti-Arch»)? I've tried to re-word it with something else, then :) Please take a look and see if this is more sensible. Best, Nileshdiff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index 69467c4..0f5933c 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -1381,8 +1381,9 @@ 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. +The ``Multi-Arch`` field does not affect udebs. +The permitted field values are ``no`` (default), ``foreign``, ``same`` and ``allowed``. Their semantics are described in the following sections. .. _s-f-Multi-Arch-no:
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
Hi! On Wed, 2026-05-13 at 17:49:29 +0530, Nilesh Patra wrote: > On 10/05/26 8:46 pm, Helmut Grohne wrote: > > I am hesitant to second the "must not" precisely for those font > > packages. > > Attached another patch, with wording changed a bit; as M-A is relevant only > for binary package > stanza (and S-V makes it to only source package stanza which would be sort of > inherited). > Please see if this is good enough. While the change does not look wrong, I'm not sure there's a need to mention that this applies to binary package stanzas, as that should be clear from the previous sentence? (Also just in case, and to clarify, neither Standards-Version nor Multi-Arch fields get inherited.) > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 69467c4..92d4dbe 100644 > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst > @@ -1381,8 +1381,9 @@ 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. > +Binary package stanzas for udebs do not make use of ``Multi-Arch``. > +The permitted field values are ``no`` (default), ``foreign``, ``same`` and > ``allowed``. Their semantics are described in the following sections. > > .. _s-f-Multi-Arch-no: Maybe just say that for udeb packages the field is not useful/used/taken-into-account/in-scope? Which should cover not only debian/control but also DEBIAN/control (for example via «dpkg-gencontrol -DMulti-Arch»)? Thanks, Guillem
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
Hi Nilesh, On Wed, May 13, 2026 at 05:49:29PM +0530, Nilesh Patra wrote: > I was planning to use something similar, but the messages in the IRC > mentioned must not, and hence I > decided to choose this instead :) I'm sorry for having misguided you here. > This will still result in 9 bugs, but not with rc severity. The train of > thought above makes > sense to me. Sounds good. > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 69467c4..92d4dbe 100644 > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst > @@ -1381,8 +1381,9 @@ 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. > +Binary package stanzas for udebs do not make use of ``Multi-Arch``. > +The permitted field values are ``no`` (default), ``foreign``, ``same`` and > ``allowed``. Their semantics are described in the following sections. > > .. _s-f-Multi-Arch-no: I second this. Helmut signature.asc Description: PGP signature
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
On 10/05/26 8:46 pm, Helmut Grohne wrote: > 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 was planning to use something similar, but the messages in the IRC mentioned must not, and hence I decided to choose this instead :) This will still result in 9 bugs, but not with rc severity. The train of thought above makes sense to me. > I am hesitant to second the "must not" precisely for those font > packages. Attached another patch, with wording changed a bit; as M-A is relevant only for binary package stanza (and S-V makes it to only source package stanza which would be sort of inherited). Please see if this is good enough. Best, Nilesh diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst index 69467c4..92d4dbe 100644 --- a/policy/ch-controlfields.rst +++ b/policy/ch-controlfields.rst @@ -1381,8 +1381,9 @@ 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. +Binary package stanzas for udebs do not make use of ``Multi-Arch``. +The permitted field values are ``no`` (default), ``foreign``, ``same`` and ``allowed``. Their semantics are described in the following sections. .. _s-f-Multi-Arch-no:
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
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
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
On 10/05/26 11:22 pm, Guillem Jover wrote: > On Sun, 2026-05-10 at 15:39:38 +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? Helmut was the one who asked me on IRC to file a bug with `M-A must not be used`. > Right, actually after having pondered a bit about this for whether to > emit a warning, error or nothing in dpkg-gencontrol, my conclusion > is that while I still agree this is not in scope, it should have no ill > effect except for increasing the .udeb size, so I think a warning is > enough (and that's what I've updated the patch to do now), and as such > for Debian Policy a must seems indeed too strong. So I rescind my > second for now. :) Mh... Is a s/must/should/ fair enough for you? If so, Sean, would you just change that before you apply this patch? Or do you want me to attach another patch?
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
Hi!
On Sun, 2026-05-10 at 15:39:38 +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?
Right, actually after having pondered a bit about this for whether to
emit a warning, error or nothing in dpkg-gencontrol, my conclusion
is that while I still agree this is not in scope, it should have no ill
effect except for increasing the .udeb size, so I think a warning is
enough (and that's what I've updated the patch to do now), and as such
for Debian Policy a must seems indeed too strong. So I rescind my
second for now. :)
Also having briefly checked the debian-installer Packages file for
amd64, I see only a handful of packages for which the field has been
explicitly set by the maintainer. This is the list for amd64, but
probably incomplete across all arches:
fonts-freefont-udeb
fonts-knda-udeb
fonts-lohit-guru-udeb
fonts-taml-udeb
fonts-sil-abyssinica-udeb
fonts-sil-padauk-udeb
fonts-thai-tlwg-udeb
fonts-ukij-uyghur-udeb
pwgen-udeb
Thanks,
Guillem
From feb8794184d9a634f8a1611e02d7eb0d531b6e86 Mon Sep 17 00:00:00 2001
From: Guillem Jover
Date: Sun, 10 May 2026 19:38:39 +0200
Subject: [PATCH] dpkg-gencontrol: Remove and warn about Multi-Arch field on
udeb packages
The udeb packages are intended to be minimal, and on Debian these target
only the Debian Installer, where multi-arch is out of scope, but the only
ill effect of having this field is the increase in size, which we handle
with the field removal.
Proposed-by: Nilesh Patra
---
scripts/dpkg-gencontrol.pl | 4
1 file changed, 4 insertions(+)
diff --git a/scripts/dpkg-gencontrol.pl b/scripts/dpkg-gencontrol.pl
index f07b9b9ea..0c4040716 100755
--- a/scripts/dpkg-gencontrol.pl
+++ b/scripts/dpkg-gencontrol.pl
@@ -346,6 +346,10 @@ my $pkg_type = $pkg->{'Package-Type'} ||
if ($pkg_type eq 'udeb') {
delete $fields->{'Package-Type'};
delete $fields->{'Homepage'};
+if (delete $fields->{'Multi-Arch'}) {
+warning(g_("package '%s' (type %s) contains out of scope %s field"),
+$oppackage, $pkg_type, 'Multi-Arch');
+}
} else {
for my $f (qw(Subarchitecture Kernel-Version Installer-Menu-Item)) {
warning(g_("%s package '%s' with udeb specific field %s"),
--
2.53.0
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
Hi!
On Sun, 2026-05-10 at 13:04:59 +0530, Nilesh Patra 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
I think this should read "The ``Multi-Arch`` field must ...".
> +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, for filing this, regardless of the wording change there,
seconded.
I'm also attaching the change that you suggested on IRC for dpkg, but
I'm undecided whether to make it warn though, will ponder about it
before pushing.
Thanks,
Guillem
diff --git i/scripts/dpkg-gencontrol.pl w/scripts/dpkg-gencontrol.pl
index f07b9b9ea..7958e6ba4 100755
--- i/scripts/dpkg-gencontrol.pl
+++ w/scripts/dpkg-gencontrol.pl
@@ -346,6 +346,7 @@ my $pkg_type = $pkg->{'Package-Type'} ||
if ($pkg_type eq 'udeb') {
delete $fields->{'Package-Type'};
delete $fields->{'Homepage'};
+delete $fields->{'Multi-Arch'};
} else {
for my $f (qw(Subarchitecture Kernel-Version Installer-Menu-Item)) {
warning(g_("%s package '%s' with udeb specific field %s"),
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
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? -- Sean Whitton
Bug#1136160: debian-policy: Clarify that Multi-Arch is not applicable for udebs
Package: debian-policy Tags: patch Hi, Patch for the same is attached. Please take a look. Best, Nileshdiff --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:
