Re: Bug#985401: dpkg: libreoffice buster->bullseye upgrade failures
Hi!
On Thu, 2021-03-18 at 18:25:17 +0100, Rene Engelhard wrote:
> Am 18.03.21 um 06:53 schrieb Rene Engelhard:
> > 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.)
>
> Sorry for my tone this morning, but waking up with a RC bug more for
> this wasn't actually making me happy in any way.
Thanks, much appreciated.
> >>> 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.
Sure, because that file on buster is owned by another package, while
the failing package also owns files there. This still looks like a
usage issue in the caller, as this behavior has not changed nor is
a regression.
> Actually I pondered filing a bug back then (wishlist) when I first saw
> this because I think dpkg should trust maintainers to do the right thing
> if they used dir_to_symlink and the ownership of the file changes.
> (That would also have saved the Conflicts)
I guess something could be added as a new feature, but taking into
account that the dpkg-maintscript-helper is a tool that tries to
cover feature deficiencies in dpkg, that should eventually be
supported natively, I'd rather not add anything that might make such
future integration not possible. But even then, this seems out of
scope at this time of the freeze.
> Is there a way to do that? Or some way to force it?
I don't see how what the packages want to do can be done as is with
debhelper's dpkg-maintscript-helpers support, it seems to break unpacking
assumptions.
If you really need the symlink, then perhaps you could try to do the
switch on the postinst of all the packages that have shipped files
there, conditional on the directory being empty, so that the last one
moving its files out of the directory would switch it (specifying
manually the package that's supposed to own the symlink).
> Then I didn't actually do it and "just" added the Conflicts:
>
> (The symlink is only needed because of LO not honouring their own
> configuration so otherwise the config is not found - see #972043 and
> #969653)
Ok, then if this is needed, see above.
Otherwise, I don't see a bug in dpkg for this here. And I'd be
inclined to close this.
Thanks,
Guillem
Reply to: