tag 541313 wontfix
thanks

Hi Colin!

On Thu, 2009-08-13 at 10:24:36 +0100, Colin Watson wrote:
> Package: dpkg
> Version: 1.15.3.1
> Severity: wishlist
> 
> When testing builds of multiple-binary packages, I often do something
> like 'dpkg -iO *.deb' to upgrade all the ones I have installed. Normally
> I do this in a clean temporary directory so there's only one version
> available, but sometimes I forget, and end up with something like this
> happening:
> 
>   $ sudo dpkg -iO *.deb
>   dpkg: warning: downgrading grub-common from 1.96+20090725-1ubuntu3 to 
> 1.96+20080228-1.
>   (Reading database ... 386705 files and directories currently installed.)
>   Preparing to replace grub-common 1.96+20090725-1ubuntu3 (using 
> grub-common_1.96+20080228-1_i386.deb) ...
>   Unpacking replacement grub-common ...
>   Preparing to replace grub-common 1.96+20080228-1 (using 
> grub-common_1.96+20090725-1ubuntu2_i386.deb) ...
>   Unpacking replacement grub-common ...
>   Preparing to replace grub-common 1.96+20090725-1ubuntu2 (using 
> grub-common_1.96+20090725-1ubuntu3_i386.deb) ...
>   Unpacking replacement grub-common ...
>   Skipping deselected package grub-coreboot.
    [...]
>   Skipping deselected package grub-linuxbios.
>   dpkg: warning: downgrading grub-pc from 1.96+20090725-1ubuntu3 to 
> 1.96+20080228-1.
>   Preparing to replace grub-pc 1.96+20090725-1ubuntu3 (using 
> grub-pc_1.96+20080228-1_i386.deb) ...
>   Unpacking replacement grub-pc ...
>   dpkg: error processing grub-pc_1.96+20080228-1_i386.deb (--install):
>    trying to overwrite `/usr/sbin/grub-mkdevicemap', which is also in package 
> grub-common
>   dpkg-deb: subprocess paste killed by signal (Broken pipe)
>   dpkg: warning: downgrading grub-pc from 1.96+20090725-1ubuntu3 to 
> 1.96+20090725-1ubuntu2.
>   Preparing to replace grub-pc 1.96+20090725-1ubuntu3 (using 
> grub-pc_1.96+20090725-1ubuntu2_i386.deb) ...
>   Unpacking replacement grub-pc ...
>   Preparing to replace grub-pc 1.96+20090725-1ubuntu2 (using 
> grub-pc_1.96+20090725-1ubuntu3_i386.deb) ...
>   Unpacking replacement grub-pc ...
>   Skipping deselected package grub-rescue-pc.
    [...]
>   Skipping deselected package grub2.
>   More than one copy of package grub-common has been unpacked
>    in this run ! Only configuring it once.
>   More than one copy of package grub-common has been unpacked
>    in this run ! Only configuring it once.
>   More than one copy of package grub-pc has been unpacked
>    in this run ! Only configuring it once.
>   Setting up grub-common (1.96+20090725-1ubuntu3) ...
>   Installing new version of config file /etc/grub.d/00_header ...
>   Processing triggers for man-db ...
>   Setting up grub-pc (1.96+20090725-1ubuntu3) ...
>   Replacing config file /etc/default/grub with new version
>   ^Cdpkg: error processing grub-pc (--install):
>    subprocess installed post-installation script killed by signal (Interrupt)
>   ^C

> I think that if dpkg is asked to unpack multiple versions of the same
> package (modulo multiarch), it could usefully simply skip all but the
> highest version.

While that's true, it's also obeying (to the letter) what the “user
requested”, which in this case I acknowledge is not that useful (but
I consider the above behaviour bogus, see below).

> (Yes, I know that either -G or -GE, depending on the circumstances, will
> have a sort of similar effect. I still think this is a useful request
> even given that; if I don't have the package installed right now and do
> 'dpkg -i *.deb', I don't see any reason why it shouldn't just use the
> newest version rather than having some random effects based on directory
> entry ordering.)

With #31141 now fixed in git, -G should behave more sanely, so if you
have in directory versions 1.0, 1.1 installed and 1.2 under development,
using -G should have the same effect as what you request, by not
downgrading on unpack to any of the previous versions.

Implementing what you request would require parsing all packages control
files first, which we are not currently doing. And while I'm not opposed
to doing that in principle, I just don't see the need to implement it
for this particular case alone, given the new behaviour of -G and -E.

So I'm tagging as wontfix for now (instead of closing, because I think
the request is valid), but if the fix in #31141 is not enough to subdue
any possible current grievance then I'm open to reconsider!

thanks,
guillem




--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

Reply via email to