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
