Re: [patch] always send the full name on the --status-fd
On Tue, Oct 15, 2013 at 05:39:39PM +0200, Guillem Jover wrote:
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
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 <firstname.lastname@example.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
> > 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.