[Debian GNUstep maintainers] Bug#1035984: libpopplerkit0: unhandled symlink to directory conversion: /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources

Andreas Beckmann anbe at debian.org
Fri May 12 09:34:12 BST 2023


Package: libpopplerkit0
Version: 0.0.20051227svn-11
Severity: serious
User: debian-qa at lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  testing -> unstable

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (scroll to the bottom...):

1m20.3s ERROR: installs objects over existing directory symlinks:
  /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/Info-gnustep.plist (libpopplerkit0) != /usr/share/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Info-gnustep.plist (?)
    /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources -> ../../../../../../share/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0


Excerpts from debdiff libpopplerkit0_0.0.20051227svn-10+b1_amd64.deb libpopplerkit0_0.0.20051227svn-11_amd64.deb

Files in first .deb but not in second
-------------------------------------
-rw-r--r--  root/root   /usr/share/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Info-gnustep.plist
-rw-r--r--  root/root   /usr/share/doc/libpopplerkit0/changelog.Debian.amd64.gz
lrwxrwxrwx  root/root   /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources -> ../../../../../../share/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0

Files in second .deb but not in first
-------------------------------------
-rw-r--r--  root/root   /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/Info-gnustep.plist


Was the move of Info-gnustep.plist from /usr/share to /usr/lib
intentional?
The easies fix would be to move it back to /usr/share and let dpkg clean
up the unused and messed up paths/symlinks in /usr/lib.


cheers,

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libpopplerkit0_0.0.20051227svn-11.log.gz
Type: application/gzip
Size: 29424 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnustep-maintainers/attachments/20230512/b724a676/attachment-0001.gz>


More information about the pkg-GNUstep-maintainers mailing list