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 <m...@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 -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131015173932.GA31332@bod
