[pkg-php-pear] Bug#736294: pkg-php-tools: causes directory vs. symlink conflicts

Andreas Beckmann anbe at debian.org
Wed Jan 22 02:26:46 UTC 2014


Package: pkg-php-tools
Version: 1.9
Severity: serious
User: debian-qa at lists.debian.org
Usertags: piuparts

Hi,

I'm filing this against the packaging helper that most probably causes
this issue, not against the affected packages.

I recently noticed new problems where packages install files over
existing symlinks during jessie -> sid upgrades. All of them had a
recent bug closed that talked about migration to pkg-php-tools.

e.g.

php-net-whois 1.0.5-1 -> 1.0.5-2
0m44.5s INFO: dirname part contains a symlink:
  /usr/share/php/tests/Net_Whois/tests/test.php (php-net-whois) != /usr/share/doc/php-net-whois/tests/test.php (?)
  /usr/share/php/tests/Net_Whois/tests/test17476.php (php-net-whois) != /usr/share/doc/php-net-whois/tests/test17476.php (?)
  /usr/share/php/tests/Net_Whois/tests/test2.php (php-net-whois) != /usr/share/doc/php-net-whois/tests/test2.php (?)
  /usr/share/php/tests/Net_Whois/tests/test6348.php (php-net-whois) != /usr/share/doc/php-net-whois/tests/test6348.php (?)
  /usr/share/php/tests/Net_Whois/tests/test_authoritative.php (php-net-whois) != /usr/share/doc/php-net-whois/tests/test_authoritative.php (?)
  /usr/share/php/tests/Net_Whois/tests/test_mult.php (php-net-whois) != /usr/share/doc/php-net-whois/tests/test_mult.php (?)
  /usr/share/php/tests/Net_Whois/tests/testza.php (php-net-whois) != /usr/share/doc/php-net-whois/tests/testza.php (?)

php-net-url2 2.0.0-1 -> 2.0.0-2
2m41.2s INFO: dirname part contains a symlink:
  /usr/share/php/tests/Net_URL2/tests/AllTests.php (php-net-url2) != /usr/share/doc/php-net-url2/tests/AllTests.php (?)
  /usr/share/php/tests/Net_URL2/tests/Net (php-net-url2) != /usr/share/doc/php-net-url2/tests/Net (?)
  /usr/share/php/tests/Net_URL2/tests/Net/URL2Test.php (php-net-url2) != /usr/share/doc/php-net-url2/tests/Net/URL2Test.php (?)

php-net-imap 1:1.1.1-1 -> 1:1.1.1-2
0m30.4s INFO: dirname part contains a symlink:
  /usr/share/php/tests/Net_IMAP/tests/IMAPTest.php (php-net-imap) != /usr/share/doc/php-net-imap/tests/IMAPTest.php (?)
  /usr/share/php/tests/Net_IMAP/tests/settings.php.sample (php-net-imap) != /usr/share/doc/php-net-imap/tests/settings.php.sample (?)

and so on ...

>From the bug templates that I usually use for the buggy packages
(which may not fully apply here):


Hi,

during a test with piuparts I noticed your package installs files over
an existing symlink shipped or created by another package.

Your package ships:


but package CONFLICTOR ships:


Installing something over existing symlinks is considered bad practice.
See e.g. http://lists.debian.org/87ehlevcrf.fsf@windlord.stanford.edu

It may break in subtle ways and dpkg cannot detect this as a problem.
* Your package might silently overwrite files installed at the symlink
  destination by other packages.
* If the package shipping the symlink decides to make the link point
  somewhere else (or turn it into a real directory), the files owned
  by your package "will be lost" somewhere in the filesystem.
* Depending on installation order the problematic path will be created
  either as a symlink or a directory: the package installed first will
  "win" and all others have "lost".
  Note that dpkg intentionally does not replace directories with
  symlinks and vice versa, see in particular the end of point 4 in
  http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase
  (Note: Adding Pre-Depends is *not* a solution.)

Please move the files shipped in your package to the "real" location.


or


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:


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:
http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

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
http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

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




Andreas



More information about the pkg-php-pear mailing list