Hi! 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? 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. 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. (As an aside, I see the code is not keying on "status:" so if there's a new record type introduced, apt might misbehave.) > >From 92f86c58f239804a71b1141302255ed6e945fb1d Mon Sep 17 00:00:00 2001 > From: Michael Vogt <[email protected]> > 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? :) > lib/dpkg/dbmodify.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) (There would be a missing unchanged instance in «src/help.c».) Thanks, Guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
