Package: pkg-php-tools Version: 1.9 Severity: serious User: [email protected] 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/[email protected] 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
