[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#985401: dpkg: libreoffice buster->bullseye upgrade failures



Control: reassign -1 libreoffice-common 1:7.0.4-3

[ Leaving all context for the reassign. ]

Hi!

On Wed, 2021-03-17 at 12:13:52 +0100, Andreas Beckmann wrote:
> Package: dpkg
> Version: 1.20.7.1
> Severity: serious
> User: debian-qa@lists.debian.org
> Usertags: piuparts
> Control: block 985297 with -1
> 
>   Preparing to unpack .../0-ure_1%3a7.0.4-3_amd64.deb ...
>   Unpacking ure (1:7.0.4-3) over (6.1.5-3+deb10u7) ...
>   Preparing to unpack .../1-libreoffice-style-colibre_1%3a7.0.4-3_all.deb ...
>   Unpacking libreoffice-style-colibre (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   dpkg: considering deconfiguration of libreoffice-writer, which would be broken by installation of libreoffice-core ...
>   dpkg: yes, will deconfigure libreoffice-writer (broken by libreoffice-core)
>   Preparing to unpack .../2-libreoffice-core_1%3a7.0.4-3_amd64.deb ...
>   De-configuring libreoffice-writer (1:6.1.5-3+deb10u7) ...
>   Unpacking libreoffice-core (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...

The libreoffice-core package has finished unpacking. Next, dpkg starts
with libreoffice-common.

>   dpkg: considering removing libreoffice-writer in favour of libreoffice-common ...
> * dpkg: libreoffice-writer is not properly installed; ignoring any dependencies on it ***
> * dpkg: yes, will remove libreoffice-writer in favour of libreoffice-common           ***

dpkg detects there's a Conflicts involved during the unpack and queues
it for later removal. (Although that removal is then silent anyway, which
seems confusing, so ideally dpkg should probably print something like we
do with the de-configuring.)

>   Preparing to unpack .../3-libreoffice-common_1%3a7.0.4-3_all.deb ...
>   dpkg-maintscript-helper: error: file '/usr/lib/libreoffice/share/registry/writer.xcd' not owned by package 'libreoffice-common:all'
>   dpkg-maintscript-helper: error: directory '/usr/lib/libreoffice/share/registry' contains files not owned by package libreoffice-common:all, cannot switch to symlink
>   dpkg: error processing archive /tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb (--unpack):
>    new libreoffice-common package pre-installation script subprocess returned error exit status 1
>   rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or directory
>   rmdir: failed to remove '/var/lib/libreoffice': No such file or directory

The libreoffice-common preinst maintainer script fails, so I'd expect
the installation for the package gets aborted and the conflictor does
not get removed after this, and before processing the next archive.

>   Selecting previously unselected package libreoffice-writer.
>   dpkg: considering deconfiguration of libreoffice-common, which would be broken by installation of libreoffice-writer ...
>   dpkg: yes, will deconfigure libreoffice-common (broken by libreoffice-writer)
>   Preparing to unpack .../4-libreoffice-writer_1%3a7.0.4-3_amd64.deb ...
>   De-configuring libreoffice-common (1:6.1.5-3+deb10u7) ...
>   Unpacking libreoffice-writer (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   Replacing files in old package libreoffice-common (1:6.1.5-3+deb10u7) ...
>   Preparing to unpack .../5-libxmlsec1_1.2.31-1_amd64.deb ...
>   Unpacking libxmlsec1:amd64 (1.2.31-1) over (1.2.27-2) ...
>   Preparing to unpack .../6-libreoffice-base-core_1%3a7.0.4-3_amd64.deb ...
>   Unpacking libreoffice-base-core (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>   Errors were encountered while processing:
>    /tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb
> 
> So is dpkg going to remove libreoffice-writer or not?

It would if the maintscript would not have failed.

> It says both and does 
> not remove it, causing dpkg-maintscript-helper to fail since
> /usr/lib/libreoffice/share/registry is not empty before dir_to_symlink
> is run. There should be enough Conflicts to ensure all packages previously
> shipping files there are removed or upgraded.

This would be an incorrect assumption from the package, policy
describes how Conflicts interact during upgrades in §6.6. Notice
there the conflictors are only removed in step 13, the last one.

Thanks,
Guillem


Reply to: