Bug#680041: aptitude: incorrect dpkg* calls

[Daniel Hartwig <mandyke@gmail.com>]

clone 680041 -1 -2
reassign -1 aptitude
retitle -1 aptitude: wrong multi-arch pkg names in dpkg call
tags -1 + confirmed
reassign -2 aptitude
retitle -2 aptitude: dpkg* calls ignoring DPkg::Options
severity -2 important
tags -2 + confirmed
--

On 5 July 2012 06:21, David Kalnischkies <kalnischkies+debian@gmail.com> wrote:
> On Tue, Jul 3, 2012 at 7:35 AM, Stepan Golosunov <stepan@golosunov.pp.ru> wrote:
>> apt-mark hold and apt-mark unhold (as well as aptitude hold) do not
>> work on Architecture: all packages:

Aptitude hold is currently broken for a variety of other reasons.  See
#137771.  Our hold-state is managed separately and not available to
other programs.

>
> (cc'ing aptitude-team so they can have a look and
>  if it effects them, too, clone the bug or something)
>
> The problem here is that APT (as defined by spec) handles arch:all packages
> as if they would be arch:native packages for various reasons
> (like supporting changes from arch:all to arch:any and vice versa).
>
> dpkg doesn't handle it that way in input (for - again - various reasons),
> so the attached patch tries to use the architecture of the installed version
> so dpkg gets the correct architecture as input, hopefully.
>
>
> If aptitude is really effected, it might be something completely different
> as packages previously had no architecture (only versions had).

Thanks for the notice.  Cloning as appropriate.

Aptitude is not effected by this particular bug *for package holds*,
due to the aforementioned #137771.  However, it does turn up in
src/pkg_item.cc which has code to this effect:

 sucmd="dpkg-reconfigure '%s'";
 snprintf(buf, 512, sucmd,
          package.FullName().c_str());

with these problems:

- arch-qualified names are always used, even if dpkg is not
  multi-arch aware;
- arch:all packages are treated as arch:native by APT but not
  dpkg (as discussed above by David) -- must use
  VerIterator::FullName instead.

That call also ignores DPkg::Options and download_install_manager.cc
has a similar call to "dpkg --configure -a".

>
> [For wheezy+1 we should have a look at providing this functionality
>  in libapt as it slowly becomes quiet a bit of code …]

Definitely. I had been noticing this in a few places, but have not yet
been able to work on it.

Regards