[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [patch] always send the full name on the --status-fd



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 <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? :)

>  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


Reply to: