Re: Bug#985401: dpkg: libreoffice buster->bullseye upgrade failures
reassign 985401 dpkg
thanks
Hi Guillem,
Am 18.03.21 um 00:02 schrieb Guillem Jover:
> Control: reassign -1 libreoffice-common 1:7.0.4-3
It would be helpful if you actually did your homework. There already was
985297 so you now caused a bogus addditional RC bug.
That bug even was marked as blocked by the dpkg bug so being careful
when reassigning RC bugs would actually be of help.
Now I have two of them. (Yes, I know about merge but still it is wrong
to reassign llike this at all.)
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.)
Want a bug for this?
>> 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.
It fails because of
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
which is dpkg-maintscript-helpers domain.
>> 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 fails because of a bug in dpkg.
>> 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.
How is dir_to_symlink working in these cases then?
No, I am not going to add hand-crafted stuff this late in the release
cycle for something which is unreproducible here anyway.
Regards,
Rene
Reply to: