On Sun, Dec 04, 2016 at 04:13:47AM +0100, Guillem Jover wrote: > On Tue, 2016-11-22 at 18:50:51 +0100, David Kalnischkies wrote: > > On Tue, Nov 22, 2016 at 02:43:35PM +0100, Vincent Lefevre wrote: > > > --\ Packages to be upgraded (17) > > […] > > > iuA nvidia-driver-libs 367.57-1 > > > 367.57-2 > > […] > > > --\ Packages being removed because they are no longer used (27) > > […] > > > idA nvidia-driver-libs:i386 -180 kB 367.57-1 > > > 367.57-2 > > […] > > > dpkg: error processing package nvidia-driver-libs:amd64 (--configure): > > > package nvidia-driver-libs:amd64 367.57-2 cannot be configured because > > > nvidia-driver-libs:i386 is at a different version (367.57-1) > > > > This looks like a bug in dpkg as it is not considering the removal of > > nvidia-driver-libs:i386 as solution to the problem it runs into here > > even through libapt has told it via selections that it wants it removed. > > Hmm, dpkg does not remove other packages at configure time, it only > ever does that at unpack time. Removing this kind of packages at > unpack time would seem gratuituous though, as it might or might not end
> up seeing an updated packages, and version-skew (I like screw too BTW :) (skew vs screw – such a typical "david"…) > is not a problem at unpack time anyway. Also remember that an unpack of > the selected to be deinstalled package would reset that selection. At least in terms of apt there is no situation in which a package would be upgraded before its removed (the other way around exists). The only time apt has to remember the reselection is with purged packages as it removes them first nowadays. So at least I would have no problem if --unpack would decide to remove the "siblings" of a M-A:same package if they are marked for removal given that this is what was requested anyhow even if the remove is strictly speaking only needed at configure time. > So, this seems like a new kind of feature to me. Also the frontends > would need to handle the current dpkg anyway when doing upgrades, so > it seems this needs to be handled in frontends right now no matter > what? libapt deals with this now (>= 1.4) and was effected only since recently (as mentioned, it "confused" it with a crossgrade), so there is no hurry needed from my PoV. It would be nice if we could stop doing (all) explicit removals using selections only for removals eventually through, but that is a buster topic… Best regards David Kalnischkies
signature.asc
Description: PGP signature
