Bug#1103995: [Pkg-rust-maintainers] Bug#1103995: unblock: rust-debcargo/2.7.8-4
- To: Fabian Grünbichler <debian@fabian.gruenbichler.email>, 1103995@bugs.debian.org
- Subject: Bug#1103995: [Pkg-rust-maintainers] Bug#1103995: unblock: rust-debcargo/2.7.8-4
- From: Sebastian Ramacher <sramacher@debian.org>
- Date: Fri, 2 May 2025 13:16:29 +0200
- Message-id: <[🔎] aBSpjT0C1RMFUIBK@ramacher.at>
- Reply-to: Sebastian Ramacher <sramacher@debian.org>, 1103995@bugs.debian.org
- In-reply-to: <7n4jj2l6o5qirkr7lavrvzrxev62s6c6ud7f3ujzsa7427bk7p@52gpq7anlqzq>
- References: <77a88e74-5ddc-4b52-bff2-3efec85234dc@app.fastmail.com> <a7efee12-c61f-450c-a584-a7690549a4b2@debian.org> <77a88e74-5ddc-4b52-bff2-3efec85234dc@app.fastmail.com> <9fc96aad-9813-4f1a-b1d4-f12083854e98@app.fastmail.com> <77a88e74-5ddc-4b52-bff2-3efec85234dc@app.fastmail.com> <7n4jj2l6o5qirkr7lavrvzrxev62s6c6ud7f3ujzsa7427bk7p@52gpq7anlqzq> <77a88e74-5ddc-4b52-bff2-3efec85234dc@app.fastmail.com>
Control: tags -1 confirmed
On 2025-04-24 08:20:50 +0200, Fabian Grünbichler wrote:
> On Thu, Apr 24, 2025 at 07:29:27AM +0200, Fabian Grünbichler wrote:
> > On Thu, Apr 24, 2025, at 2:13 AM, Peter Green wrote:
> > >>
> > >> If preferred, a variant of the proposed changes with a default of "no" would
> > >> also be possible
> > >
> > > I think the default (for bin packages) should be not to generate a multi-arch:
> > > field at all.
> > >
> > > This is behaviorally equivalent to multi-arch: no, but it IMO has different
> > > implications, it implies "noone has thought about multi-arch for this package"
> > > rather than "sometime has thought about multi-arch for this package and
> > > rejected it"
> >
> > Thanks for the quick feedback!
> >
> > Helmut Grohne raised a similar objection on IRC, and like I noted in unblock
> > request, that works just as well. Having "no" as default is easiest, having
> > no default (which like you say, is "behaviorally equivalent") means a bit
> > more code changes, but can be supported as well.
>
> debdiff for the "set no value by default" variant attached, rationale
> remains identical to initial report.
Please go ahead with the version no value per default.
Cheers
--
Sebastian Ramacher
Reply to: