[Aptitude-devel] Bug#680334: aptitude: incorrect dpkg* calls
Manuel A. Fernandez Montecelo
manuel.montezelo at gmail.com
Thu Mar 10 12:23:31 UTC 2016
Control: tags -1 + pending
Control: owner -1 !
2012-07-05 05:12 Daniel Hartwig:
>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
dpkg-reconfigure to be removed, so this problem gone.
>and download_install_manager.cc
>has a similar call to "dpkg --configure -a".
I tried to see if I could outsource the responsibility to do this to
apt, running with DPkg::Options and all, but it seems that there isn't a
way.
That call is infrequent enough (happens only in the cases of some
detected breakage) and DPkg::Options probably not used widely enough
that this problem (if somebody stumbled upon it at all) was not reported
for years in aptitude.
In fact, despite being marked as "important", there is not real bug
report in aptitude and the messages are largely about theoretical cases,
no report came in the last few years related with it.
So with the removal of dpkg-configure, marking this bug as +pending.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>
More information about the Aptitude-devel
mailing list