Hi,

Patch for the same is attached. Please take a look.

Best,
Nilesh

Nilesh Patra [10/May  1:04pm +0530] wrote:

Thanks.  Helmut, do you agree with using a "must not" here?

Hi!

I think this should read "The ``Multi-Arch`` field must ...".

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

Hi!

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

Helmut was the one who asked me on IRC to file a bug with `M-A must not be used`.
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?

Hi,

thank you Nilesh for getting this started.

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

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.

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

Hi Nilesh,

I'm sorry for having misguided you here.

Sounds good.

I second this.

Helmut

Hi!

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

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

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.

I've tried to re-word it with something else, then :)
Please take a look and see if this is more sensible.

Best,
Nilesh

Hi!

No worries, and nothing to apologize for!

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

Attached another patch to match the phrasing. Let me know if this could
make the cut :)

Best,
Nilesh

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] <helmut> 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] <guillem> 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] <gargantua_kerr> I was under the impression that policy editors will pick it up after you folks second it...
[19:52:18] <gargantua_kerr> I'll just relay this on the bug report

Nilesh Patra [22/May  7:58pm +0530] wrote:

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.

Nilesh Patra [23/May  4:29pm +0530] wrote:

Seconded.

Hi!

To me this still has the issue I pointed out in an earlier mail.

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

Wanted to bubble up this and wished to know where we are on this.

Is there a consensus on the preferred wording finally?

Nilesh Patra [23/Jun 12:00am +0530] wrote:

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?

Nilesh Patra [23/Jun  8:25pm +0530] wrote:

I think the one I seconded is better.

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 second this version. I recognize Guillem's concern, but that does not
lead me to rejecting this version.

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

I agree and like Helmut I second both patches quoted below as well.

Helmut Grohne [23/Jun  7:03pm +02] wrote:

Thanks, pushed to the 'next' branch.