Re: [patch] always send the full name on the --status-fd
On Tue, 2013-10-15 at 19:39:32 +0200, Michael Vogt wrote:
> On Tue, Oct 15, 2013 at 05:39:39PM +0200, Guillem Jover wrote:
> > 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).
Yeah, that makes sense, also if this would help in making interaction
with dpkg easier, we should try to tackle it.
> > 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).
If we are going to add a new format, we might as well add any
additional information that frontends might find useful and that makes
sense sending. We can also cleanup the format and make it more sane
and consistent. Perhaps also in deb822-style, inspired from the
APT::Status-deb822-Fd comment in apt's changelog. :) But perhaps
that complicates the parsing too much?
I'm not sure what's your policy regarding backward compat, and when
you consider a hard dependency on a newer dpkg version is enough to be
able to remove old code, but it should eventually make things better.
dpkg will not have that luxiry though. :)
> > 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.
Cool.
> > (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.
I might not be looking at the right place or maybe the code has not
been pushed, but I don't see a fix for this?
> > 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.
Here I was mostly thinking about dpkg downstreams who have not
switched their distributions to multi-arch, and as such will never get
anything arch-qualified.
In any case as mentioned above, I'm absolutely fine with adding an
explicit option to select a new status format. Either --status-fd-format
or similar. We'd need to come up first with that'd frontends need from
it.
Thanks,
Guillem
Reply to: