Re: [patch] always send the full name on the --status-fd
On Tue, Oct 15, 2013 at 05:39:39PM +0200, Guillem Jover wrote:
> Hi!
Hi,
thanks for your mail!
> On Tue, 2013-10-15 at 07:56:28 +0200, Michael Vogt wrote:
> > I would like to ask for the inclusion of the attached patch. It simply
> > makes dpkg always send the full pkgname:arch on the status-fd. This
> > will help the progress reporting code in apt. There is code in apt now
> > to deal with this case so its not urgent, but it still would be nice
> > if the status-fd had the full information for the frontends.
>
> Help the progress reporting code as in making it simpler or something
> else?
It would help making the current code simpler and more consistent. But
apt has enough information to work without it.
Still, it feels (to me at least) a bit odd that I can do:
"""
root@amd64:# dpkg -i --status-fd 1 4g8_1.0-3_i386.deb
Preparing to replace 4g8 1.0-3 (using .../archives/4g8_1.0-3_i386.deb)
...
processing: upgrade: 4g8
status: 4g8: half-configured
...
"""
and not get any information from the status-fd about the i386
arch. But it seems like my patch is not correct anyway, when I test it
in the above scenario, I always get the architecture from the installed
package not from the new package.
My expectation would be that the status-fd tell me a little bit more
about what is going on and that I don't have to keep this state
somewhere else (i.e. that a i386 install was triggered).
> I guess I still have the same issue with this as when devising the
> current rationale for this: backward-compatibility with other dpkg
> users not switching to multiarch.
This could be controlled via e.g. a switch, but given that apt would
have to support the old behavior for some time I guess the net win is
very small (for apt).
> My impression is that this and previous problems with arch-qualifiers
> in apt stem from the divergent world view between dpkg and apt. Just
> having skimmed now over pkgDPkgPM::ProcessDpkgStatusLine, I see that
> it's always arch-qualifying unqualified package names with the apt
> native architecture (not even dpkg's), for packages that could be
> foreign for both.
Indeed, that was a misunderstand on my part what dpkg is sending. This
is fixed now in git.
> (As an aside, I see the code is not keying on "status:" so if there's a
> new record type introduced, apt might misbehave.)
Correct, thanks for pointing this out. The code is currently getting
reworked and this was one of the issues fixed.
> > >From 92f86c58f239804a71b1141302255ed6e945fb1d Mon Sep 17 00:00:00 2001
> > From: Michael Vogt <mvo@debian.org>
> > Date: Sat, 7 Sep 2013 09:36:55 +0200
> > Subject: [PATCH] Always send the architecture with the pkgname on the
> > status-fd
> >
> > The status-fd currently get the architecture information for some
> > packages but not for all packages. So fontends not expecting the
> > architecture information will break in subtle ways, i.e. progress
> > does not go from 0-100% as the frontend expects package names
> > without architecture information and gets some with and some without.
> >
> > By always sending the architecture information this is consitent.
>
> I'm not clear on the reason stated here, frontends not expecting the
> arch-qualifier will break, but we send it always so that they
> consistently break? :)
Well, frontends who can't deal with them will break when they get
"multiarch: same" packages which will happen on a lot of systems. So I
suggest to break them in a more obvious way :) Apt had the progress
calculation bug because it didn't deal with the mixed policy. And
there is always the option to opt-in into this new mode in order to
not break old clients - then dpkg could simply never send architecture
information over the "old" style status-fd and always on the new-style
one.
> > lib/dpkg/dbmodify.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> (There would be a missing unchanged instance in «src/help.c».)
Ups, I overlooked this, thanks for pointing it out. Happy to fix it if
there is a chance that the patch is considered.
Cheers,
Michael
Reply to: